Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Ideas for passing records back to calling form
Message
From
23/09/2015 14:34:20
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
23/09/2015 12:58:47
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 8
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01624724
Message ID:
01625004
Views:
82
>>>Performance is important to any application, but it is not at the top spot. Having a well designed application that is maintainable is much more important than to optimize everything unconditionally. When performance does matter, there are always other ways of optimizing your app.
>
>>I am missing nothing. Too many have this incorrect belief that speed is not important. Every customer I hear complains about the speed of every programmer.
>
>See the line from me, above yours. I'm not disputing performance is not important. However a well designed application is more important.
>Also, it makes no sense to go into great lengths trying to get a few % more performance in a routine that a user only executes a couple of times a day.

The concept of adopting the data session of the calling form has a visible performance improvement. It is applied to all forms and so applies every time the user moves among screens.
>
>Thereby breaking the encapsulation. If you expose the data from another form, the form is not encapsulated anymore. If there is a problem in the exposed data, the problem now extents into the called form. Somehow you have a problem in seeing that.

Encapsulation is not a carved in stone thing. That is the problem you have. Breaking encapsulation, stupidly and accidentally is the thing that encapsulation is intended to defend against.

>I would never use SEEK() in a VFP, SQL SELECT to lookup a value in another table, unless there is A VERY GOOD reason to do so. Just an extra join would do the trick just fine, even if it ends up a few ms slower. Else it creates an incredible mess and a huge potential for difficult to track bugs (imagine what happens if you suddenly decide to put a filter in the SEEK targetted table).

I have inherited a system where seek was used all over. I asked for a way to get around that and get nothing but lectures about concepts few seem to really appreciate.

>
>Improvements in design. Improvements in readability, maintainability. Improvements in an efficient GUI, improvements in establishing standards, yes. But trying to hunt for a few percent of performance while it is not sure if the user will ever notice it, is madness.

I get improvements in all of these areas and speed.
Previous
Reply
Map
View

Click here to load this message in the networking platform