ControlSource 
Author Message
 ControlSource


Quote:
>In Visual FoxPro V5.0...
>What are the advantages, or disadvantages, to linking screen objects
>directly to their corresponding table elements via the controlsource
>property. For example, the textbox object txtcustid might have a
>controlsource property of customer.custid, a field in the customer table. I
>could also designate a controlsource property of m.custid, a memory
>variable created by a SCATTER command in the underlying code. Do either of
>these methods utilitize or compromise the integrity of my tables?
>Thank you in advance for your reply.

>Bob Braunlich
>The Computer Resource Company

Bob:
Binding fields directly to tables means that you no longer have to do
any of that SCATTER/GATHER stuff from old Foxpro.  Of course, it also
means that whatever view/table you use cannot have its record pointer
changed or the screen display will change also.

Hope this helps.



Mon, 06 Sep 1999 03:00:00 GMT  
 ControlSource

On Thu, 20 Mar 1997 06:11:02 -0800, "Robert G. Braunlich IV"

Quote:

>In Visual FoxPro V5.0...
>What are the advantages, or disadvantages, to linking screen objects
>directly to their corresponding table elements via the controlsource
>property.

In general, there's not much use in the SCATTER/GATHER technique that
we've done in Fox in the past, especially if the program is
standalone. (An exception would be SCATTERing to an array, changing
some elements in the array, then INSERTing into the same table)

The most prevalent reason to do SCATTER/GATHER was to provide some
kind of buffering for either multi-user or rollback considerations,
however, Fox now gives us the tools to do that work more efficiently
through transactions and data buffering.
----------------
David M. Stowell
D. M. Stowell Consulting



Mon, 06 Sep 1999 03:00:00 GMT  
 ControlSource

In Visual FoxPro V5.0...
What are the advantages, or disadvantages, to linking screen objects
directly to their corresponding table elements via the controlsource
property. For example, the textbox object txtcustid might have a
controlsource property of customer.custid, a field in the customer table. I
could also designate a controlsource property of m.custid, a memory
variable created by a SCATTER command in the underlying code. Do either of
these methods utilitize or compromise the integrity of my tables?
Thank you in advance for your reply.

Bob Braunlich
The Computer Resource Company



Mon, 06 Sep 1999 03:00:00 GMT  
 ControlSource

Hi Robert!

If you are using controlsource to link the object to a field in a
table, the changes are made directly to the field. Also you can
use buffering (table or row) to have the opportunity to cancel the
changes ( tablerevert() ).

Balazs Simon



Quote:
> In Visual FoxPro V5.0...
> What are the advantages, or disadvantages, to linking screen objects
> directly to their corresponding table elements via the controlsource
> property. For example, the textbox object txtcustid might have a
> controlsource property of customer.custid, a field in the customer table.
I
> could also designate a controlsource property of m.custid, a memory
> variable created by a SCATTER command in the underlying code. Do either
of
> these methods utilitize or compromise the integrity of my tables?
> Thank you in advance for your reply.

> Bob Braunlich
> The Computer Resource Company



Mon, 06 Sep 1999 03:00:00 GMT  
 ControlSource

The disadvantage of using memory variables is that these memory variables
must be made public to expose them. Not only are they exposed to this
program but all others running in the same session.

This seems dangerous!



Quote:
> In Visual FoxPro V5.0...
> What are the advantages, or disadvantages, to linking screen objects
> directly to their corresponding table elements via the controlsource
> property. For example, the textbox object txtcustid might have a
> controlsource property of customer.custid, a field in the customer table.
I
> could also designate a controlsource property of m.custid, a memory
> variable created by a SCATTER command in the underlying code. Do either
of
> these methods utilitize or compromise the integrity of my tables?
> Thank you in advance for your reply.

> Bob Braunlich
> The Computer Resource Company



Tue, 07 Sep 1999 03:00:00 GMT  
 ControlSource


Quote:

> In Visual FoxPro V5.0...
> What are the advantages, or disadvantages, to linking screen objects
> directly to their corresponding table elements via the controlsource
> property.

The primary disadvantage, in my mind, is that you violate
encapsulation.  By linking a control to a table the control has to
"know" too much about the table structure.

Another "potential" disadvantage relates to changing each control.  Some
projects can get out of hand with code being scattered across many
controls.  I find it very helpful to be able to stay with a three tiered
model of a Data Store, Business Rules (Domain Model), and User
Interface, just sending messages from the UI through the Model, to the
data store.  This tracks with OO artifacts, and helps me to document my
work.

Generally bound data will cause you scaling problems over the life of a
project.

Of course, common sense should prevail if you have a tight timeline or
are not experienced in OOA/OOD.

HTH
John Orr



Sun, 12 Sep 1999 03:00:00 GMT  
 ControlSource



Quote:
> In Visual FoxPro V5.0...
> What are the advantages, or disadvantages, to linking screen objects
> directly to their corresponding table elements via the controlsource
> property. For example, the textbox object txtcustid might have a
> controlsource property of customer.custid, a field in the customer table.
I
> could also designate a controlsource property of m.custid, a memory
> variable created by a SCATTER command in the underlying code. Do either
of
> these methods utilitize or compromise the integrity of my tables?

There's a third way here, which is what I use. I used to use SCATTER/GATHER
(or actually, setting the memvars directly), but now I just use Data
Buffering. That gives you all the benefits of S/G without working directly
with the data.

If you turn Buffering on, either in the form or with the individual cursors
in the data environment, you are effectively working with memvars. Once you
finish working with the record (or table), you use the TableUpdate()
function to commit the changes, or TableRevert() to take them back out. If
you use Row buffering, there is an implicit TableUpdate when you move the
record pointer.

Buffering also lets you use Transactions. This provides another level of
buffering, which lets you make sure that multiple tables can update before
committing everything (no half-saved invoices, in other words.)
----begin pseudocode----
BEGIN TRANSACTION

llGoodTrans = .T.

IF NOT TABLEUPDATE(1, .F., 'table1')
        llGoodTrans = .F.
ENDif
IF NOT TABLEUPDATE(1, .F., 'table2')
        llGoodTrans = .F.
ENDif

IF llGoodTrans
        END TRANSACTION
ELSE
        ROLLBACK
        TABLEREVERT(.T., 'table1')
        TABLEREVERT(.T., 'table2')
ENDif
----end pseudocode----

Try writing that one with SCATTER/GATHER. :-)
--
Garrett Fitzgerald
Software R&D
MicroKnowledge, Inc.
Bangor, ME



Sun, 12 Sep 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Grid Column ControlSource Question

2. Combo box and integer controlsource

3. Controlsource and inputmask for datetime columns

4. Help : property controlsource

5. problem refreshing a programatically assigned controlsource

6. ControlSource ?

7. How to reopen FORM Grid ControlSource

8. Object stays disabled after change of controlsource

9. ControlSource not working

10. Can't change ControlSource in a Text box

11. how to read invalid controlsource value

12. Grids and Controlsources

 

 
Powered by phpBB® Forum Software