Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
I am not familiar with OOPS, but Foxpro. What should I focus? 7
- Thread starter Venkatvc
- Start date
I would start by getting the basics of the database down - assuming you are thinking of using the native VFP - understand how the indexes and so forth differ from the old FoxPro.
Then I would leap in and try to make a simple application that brings up a form with a button and a caption that says 'hello world' or something when you click on the button.
Do you have a specific project in mind?
Regards
Griff
Keep [Smile]ing
Then I would leap in and try to make a simple application that brings up a form with a button and a caption that says 'hello world' or something when you click on the button.
Do you have a specific project in mind?
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
Griff has started on a very VFP specific topic. And there is a lot of very VFP specific things to learn, that's for sure. VFP has a simple OOP model offering less than .NET, or Java, still enough to learn, but inheritance and using classes is not the major paradigm shift you're confronted with as legacy FoxPro developer, you go from a very workflow-oriented way of guiding users through several READS to the parallelism Windows applications mean not only using several applications in parallel on a desktop but also allowing usage of several forms in parallel within the same application (MDI) and also being able to focus on controls with the mouse in any order or tabbing through controls in each single forms.
You know the deal whether you use any Windows application with similar forms or just the internet in general. It's a norm beyond Windows and it can still work in many ways with or without a submit/save/cancel/ok button. Now you learn the behind the scenes of that.
Griff's advice points out this vast difference between the legacy way of programming a screen with a workflow and defined READ points. It's an important lesson to learn that and to never use READ anymore and instead do all that with one central READ EVENTS. Instead of READ meaning "now wait for input in the active @gets" or similar, READ EVENTS means "now wait for and process events. Any events, of everything running."
READ EVENTS often is and remains unknown until you first build an EXE to see it start and finish right away. To make this short, I summarized RERAD EVENTS and some other aspects in my faq184-6512. Use the VCX code to go the OOP route.
A starting point, even using VFP9 may be Hentzenwerke's book "Advanced Object-Oriented Programming With Visual Foxpro 6.0". You'll learn the basics that also didn't change much with further VFP versions.
Let's establish the importance of inheritance, even though you won't see how you profit from it right away. At some point, you'll have the challenge to establish some core behavior in all textboxes or a group of them and then you better had a class every single control or group of control inherits from and just program this behavior once and use it many times, the core idea of OOP.
This even starts out earlier in thinking of a good class hierarchy. Think big, think you have several customers for whom you want to adapt your own code with specific differences, and also think big in that you may develop several applications for the same customer but different users having other preferences. That can happen on the whole application level, on the form level and even on the control level, so you better have a hierarchy of classes that get more and more specific.
That's not hard in itself, it's the nature of inheritance anyway, you inherit what already is established on the root/base level and extend that mainly. Sometimes you override things by not calling inherited code, but most of the time you'll do. One strategy addressing the specializing from VFP to yourself to customer to application is to have the class levels exactly that way: A base level that is for general changes affecting every code and forms you ever write, then your own level where you get more specific, still generally for all customers and then you'll have a level that'll be customer-specific and then finally application-specific.
But don't start developing your own OOP application framework as the first task, nor get one and learn it, neither of these extremes teaches you OOP. Start with smaller exercises and see where that leads you.
Bye, Olaf.
Olaf Doschke Software Engineering
You know the deal whether you use any Windows application with similar forms or just the internet in general. It's a norm beyond Windows and it can still work in many ways with or without a submit/save/cancel/ok button. Now you learn the behind the scenes of that.
Griff's advice points out this vast difference between the legacy way of programming a screen with a workflow and defined READ points. It's an important lesson to learn that and to never use READ anymore and instead do all that with one central READ EVENTS. Instead of READ meaning "now wait for input in the active @gets" or similar, READ EVENTS means "now wait for and process events. Any events, of everything running."
READ EVENTS often is and remains unknown until you first build an EXE to see it start and finish right away. To make this short, I summarized RERAD EVENTS and some other aspects in my faq184-6512. Use the VCX code to go the OOP route.
A starting point, even using VFP9 may be Hentzenwerke's book "Advanced Object-Oriented Programming With Visual Foxpro 6.0". You'll learn the basics that also didn't change much with further VFP versions.
Let's establish the importance of inheritance, even though you won't see how you profit from it right away. At some point, you'll have the challenge to establish some core behavior in all textboxes or a group of them and then you better had a class every single control or group of control inherits from and just program this behavior once and use it many times, the core idea of OOP.
This even starts out earlier in thinking of a good class hierarchy. Think big, think you have several customers for whom you want to adapt your own code with specific differences, and also think big in that you may develop several applications for the same customer but different users having other preferences. That can happen on the whole application level, on the form level and even on the control level, so you better have a hierarchy of classes that get more and more specific.
That's not hard in itself, it's the nature of inheritance anyway, you inherit what already is established on the root/base level and extend that mainly. Sometimes you override things by not calling inherited code, but most of the time you'll do. One strategy addressing the specializing from VFP to yourself to customer to application is to have the class levels exactly that way: A base level that is for general changes affecting every code and forms you ever write, then your own level where you get more specific, still generally for all customers and then you'll have a level that'll be customer-specific and then finally application-specific.
But don't start developing your own OOP application framework as the first task, nor get one and learn it, neither of these extremes teaches you OOP. Start with smaller exercises and see where that leads you.
Bye, Olaf.
Olaf Doschke Software Engineering
Bit daunting when you put it like that Olaf...
Regards
Griff
Keep [Smile]ing
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
Why Griff, OOP isn't a thing you learn within a few days or weeks or even months and not on the go.
Bye, Olaf.
Olaf Doschke Software Engineering
Bye, Olaf.
Olaf Doschke Software Engineering
Mike Lewis
Programmer
You've got a point, Griff. All the more reason to start gradually, and to take it one step at a time.
Venkatvc, when I used to run VFP courses, we would always start by creating a simple, stand-alone data-entry form. It was a good way of learning the basic techniques: how to bind a form to a data source, how to customise the form's appearance, and how to add basic functionality like saving or reverting the user's edits. That led to the next step, which was creating generic controls and adding them to the form. For example, a simple navigator (to go to first / previous / next / last record). And we progressed from there.
It was only quite a bit later that I would cover the more theoretical elements of OOP, such as class hierarchies, inheritance and polymorphism. By that time, the trainees would be comfortable working with objects, properties, methods and events.
This approach might be a good way for you to get started. And don't forget that you can always come back here if you have any specific questions.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Venkatvc, when I used to run VFP courses, we would always start by creating a simple, stand-alone data-entry form. It was a good way of learning the basic techniques: how to bind a form to a data source, how to customise the form's appearance, and how to add basic functionality like saving or reverting the user's edits. That led to the next step, which was creating generic controls and adding them to the form. For example, a simple navigator (to go to first / previous / next / last record). And we progressed from there.
It was only quite a bit later that I would cover the more theoretical elements of OOP, such as class hierarchies, inheritance and polymorphism. By that time, the trainees would be comfortable working with objects, properties, methods and events.
This approach might be a good way for you to get started. And don't forget that you can always come back here if you have any specific questions.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Not sure, honestly, how much grasp of OOP you need to get started in VFP.
Regards
Griff
Keep [Smile]ing
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
-
1
- #8
Griff,
You make a good point.
I remember in the early VFP 3.0 days, and then shortly following VFP 5.0, it was often suggested to "Use VFP as a better FoxPro".
The other thing that was always staunchly recommended was, subclass all your base classes immediately, before you ever touch any of them, and then ONLY touch your subclasses.
I remember doing just that, and never regretting it.
It's a bit hard to come by these days, but there was a great VFP6 CD training series that I actually used to make the leap from FP2.6 to VFP (after several failed attempts in the 3 and 5 versions). It was excellent, and I think 8 or 9 CDs which I worked through in the course of about 4-6 weeks, and after that I had "crossed the void". It was good. Unfortunately I no longer have it, and I can't remember the name of it (who produced it).
It came with work books and CDs... maybe someone else remembers this and can maybe then find it on eBay or something like that. Sorry I can't be more useful there. The series was a little annoying at times, but the content and the guided examples was what made it happen for me.
Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS
"I try to be nice, but sometimes my mouth doesn't cooperate.
You make a good point.
I remember in the early VFP 3.0 days, and then shortly following VFP 5.0, it was often suggested to "Use VFP as a better FoxPro".
The other thing that was always staunchly recommended was, subclass all your base classes immediately, before you ever touch any of them, and then ONLY touch your subclasses.
I remember doing just that, and never regretting it.
It's a bit hard to come by these days, but there was a great VFP6 CD training series that I actually used to make the leap from FP2.6 to VFP (after several failed attempts in the 3 and 5 versions). It was excellent, and I think 8 or 9 CDs which I worked through in the course of about 4-6 weeks, and after that I had "crossed the void". It was good. Unfortunately I no longer have it, and I can't remember the name of it (who produced it).
It came with work books and CDs... maybe someone else remembers this and can maybe then find it on eBay or something like that. Sorry I can't be more useful there. The series was a little annoying at times, but the content and the guided examples was what made it happen for me.
Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS
"I try to be nice, but sometimes my mouth doesn't cooperate.
-
1
- #9
TamarGranor
Programmer
I wrote this article with a few others a long time ago. It may help you:
Tamar
Tamar
Olaf Doschke
Programmer
That's a good overview article by Tamar. Indeed you are more confronted with the change from a structured program having a single pass even considering loops and branching at some points. Now you have a form and control objects and a lot of events happening. Tamar also points out learning to use the debugger. You can follow the program flow there, but indeed following events is tricky with it, as the debugger itself can interfere when a form or the active control loses focus while you debug.
It's important to know about events and their role and order. The debugger offers event tracking, you can set that up visually or via SET EVENTTRACKING and SET EVENTLIST. There is a limitation of this, it only covers events of VFP controls and not what other events are happening in OLE controls. I, therefore, would also recommend learning about logging what is executed line by line with SET COVERAGE. Pros and Cons: The coverage logging does not log events happening when no code is in them, but otherwise it gives you a protocol of what ran as straight forward, as it gets. Even without using the Coverage Profiler tool. That also has another intention than displaying what code executed, it's mainly having two modes showing performance and in the other name giving mode, showing which lines of code are covered within the logged execution. So actually it's meant as a text tool telling you when you write tests (Unit tests) whether your test calls branched into any if/else branch or case and your tests, therefore, cover to execute all code lines in all the cases you have thought of. So that's a brief excursion to testing software, where you would define test calls that should test all cases, even the corner cases, so all code foreseen is executed within tests to see whether there are conditions breaking it, for example causing a non-compilable macro-substituion or type error or whatever other errors are not predictable and detectable already by compiling.
It's most important to know about control focus event order, first a WHEN event happens WHEN the control will get the focus before it has it, that's where you can still intervene and reject becoming the focus, then GOTFOCUS, then VALID and LOSTFOCUIS. Read up on all these events, their help topics will also tell you how sometimes their return value plays a role in controlling behavior. The VALID event is very special in that case. You can't just control the focus to stay as long as the input is INvalid with Return .F. or accept the input by doing nothing (which always defaults to RETURN .T.), you can also return a number being how many TABs to further controls, so RETURN 0 is like .F. staying, RETURN 1 is next control in tab order and RETURN -1 previous. It's rarely of importance but good to know, as the third option is also to simply return the object reference (you should look up what that means) to the control you want to get focus next, eg you can, for example, return THISFORM.Text5 from Thisform.Text2.Valud() event.
OK, I'm very deep diving on a detail here. These things are also covered in more general Hentzenwerke books about programming in VFP.
Anyway, don't just concentrate on how to handle objects, if you don't look into inheritance early, you'll one day be confronted with the situation, that you can't retrofit a class hierarchy into your forms, when all you use are the native base controls.
Bye, Olaf.
Olaf Doschke Software Engineering
It's important to know about events and their role and order. The debugger offers event tracking, you can set that up visually or via SET EVENTTRACKING and SET EVENTLIST. There is a limitation of this, it only covers events of VFP controls and not what other events are happening in OLE controls. I, therefore, would also recommend learning about logging what is executed line by line with SET COVERAGE. Pros and Cons: The coverage logging does not log events happening when no code is in them, but otherwise it gives you a protocol of what ran as straight forward, as it gets. Even without using the Coverage Profiler tool. That also has another intention than displaying what code executed, it's mainly having two modes showing performance and in the other name giving mode, showing which lines of code are covered within the logged execution. So actually it's meant as a text tool telling you when you write tests (Unit tests) whether your test calls branched into any if/else branch or case and your tests, therefore, cover to execute all code lines in all the cases you have thought of. So that's a brief excursion to testing software, where you would define test calls that should test all cases, even the corner cases, so all code foreseen is executed within tests to see whether there are conditions breaking it, for example causing a non-compilable macro-substituion or type error or whatever other errors are not predictable and detectable already by compiling.
It's most important to know about control focus event order, first a WHEN event happens WHEN the control will get the focus before it has it, that's where you can still intervene and reject becoming the focus, then GOTFOCUS, then VALID and LOSTFOCUIS. Read up on all these events, their help topics will also tell you how sometimes their return value plays a role in controlling behavior. The VALID event is very special in that case. You can't just control the focus to stay as long as the input is INvalid with Return .F. or accept the input by doing nothing (which always defaults to RETURN .T.), you can also return a number being how many TABs to further controls, so RETURN 0 is like .F. staying, RETURN 1 is next control in tab order and RETURN -1 previous. It's rarely of importance but good to know, as the third option is also to simply return the object reference (you should look up what that means) to the control you want to get focus next, eg you can, for example, return THISFORM.Text5 from Thisform.Text2.Valud() event.
OK, I'm very deep diving on a detail here. These things are also covered in more general Hentzenwerke books about programming in VFP.
Anyway, don't just concentrate on how to handle objects, if you don't look into inheritance early, you'll one day be confronted with the situation, that you can't retrofit a class hierarchy into your forms, when all you use are the native base controls.
Bye, Olaf.
Olaf Doschke Software Engineering
That is a good primer Tamar, thank you.
Wish I had read it back in the day instead of just piling in.
I never did write a set of base classes - just used the ones provided and wrote code to add things when I wanted them - like adding
a context menu to all edit and text boxes to provide a spell checker or a date picker or... well anything really.
It's one of the beauties of VFP, everything is in some kind of table - and you can process the tables like any other kind of data.
I think I would recommend learning how to use the Code References tool above all else, personally.
Regards
Griff
Keep [Smile]ing
Wish I had read it back in the day instead of just piling in.
I never did write a set of base classes - just used the ones provided and wrote code to add things when I wanted them - like adding
a context menu to all edit and text boxes to provide a spell checker or a date picker or... well anything really.
It's one of the beauties of VFP, everything is in some kind of table - and you can process the tables like any other kind of data.
I think I would recommend learning how to use the Code References tool above all else, personally.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
-
2
- #12
Mike Lewis
Programmer
I completely agree about the importance of sub-classing all the built-in classes and then only using those sub-classes (or their descendants). There is no question about the value of that approach.
But ... I would argue that it is not a first step in learning OOP. There is no point in diving in and starting to create sub-classes before you understand what a sub-class is and why they are important. And before that, you have to be completely clear in your mind about the difference between objects and classes.
That's why I suggested starting with a simple form, adding objects to it and modifying their properties. The fact that those objects will be based directly on the built-in classes doesn't matter from the point of viewing of learning the theory.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
But ... I would argue that it is not a first step in learning OOP. There is no point in diving in and starting to create sub-classes before you understand what a sub-class is and why they are important. And before that, you have to be completely clear in your mind about the difference between objects and classes.
That's why I suggested starting with a simple form, adding objects to it and modifying their properties. The fact that those objects will be based directly on the built-in classes doesn't matter from the point of viewing of learning the theory.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
-
1
- #13
Olaf Doschke
Programmer
I have nothing against learning objects, methods, properties first, then stepping into the inheritance and other concepts. It's natural, because you can't plan how to use something you don't know yet. That's why I also said it's a thing that's taking its time. and the extremes of letting others do the OOP job for you via an application framework you buy and learn is not getting you into the subject just like it's far too eager to start developing your own framework.
Anyway, you can and should learn it intertwined. If you start saying learning OOP is hard and you can shift it to later, then this will be procrastinated forever. It's as if a dietitian starts telling you deserts are not wrong and good for your soul and you therefore never get to healthy nutrition.
The simplest OOP concept is inheritance and you see the biggest advantage when you see that changing one base class property like FontName or FontSize changes all child classes and objects of child classes you put onto a form, too. So you can, for example, centralize some very basic settings to only do them once or a few times only at least - as VFP, unfortunately, has a caption property on multiple base classes, and they don't inherit from a central font base class. But you get the idea.
Only seeing that working inspires learning more about this "magic" of reusability.
Just a simple example: Have one onscreenkey class, add a property "focusedcontrol" and this code
This will cover most of the keys on an onscreen keyboard (eg for tablet devices used via touch interface when users don't have a mouse or keyboard attached, as in a POS station)
You don't need this code in ~100 buttons on a form or container, you just need to change the caption so the button code causes the same as a real keyboard key with that caption.
And if you want to add behavior like acting with CAPSLOCK or SHIFT (virtual SHIFT) pressed at the same time, then it's sufficient to do that in the one onscreenkey class. You might want to subclass letter keys to make use of UPPER(This.Caption), whereas that doesn't work for numeric keys in row 1 of a keyboard, so there you also have a motivation to do that. And it's all not very complicated code.
This would be some small exercise to start with and finish as an on-screen keyboard.
That said, specifically about this there's something on board of the Windows system, called OSK.exe and Yousfi Benameur wrote about how to make use of that: so forget about saying this all works easier when you design buttons for a toolbar, which doesn't remove the focus in the first place, indeed this has so much details that you better make use of a system component. It's still a nice exercise to use for learning something. A nice example of how you only write something once you use 100 times. You can even spare to manually design 100 keys when you let a loop create the key button objects. fed by the metadata of keyboard layout coming from a string like "QWERTYUIOP" (just as a hint).
The more you want to be able to learn AND also use what you created in your exercising of OOP, the more I would NOT go a route of fast progress in the sense of doing something that lets you see fast results. You'll need to be willing to throw away things you create as exercise anyway, but it doesn't have to be everything you first do in the darkness about some concepts that first don't seem appealing and beneficial.
Bye, Olaf.
Olaf Doschke Software Engineering
Anyway, you can and should learn it intertwined. If you start saying learning OOP is hard and you can shift it to later, then this will be procrastinated forever. It's as if a dietitian starts telling you deserts are not wrong and good for your soul and you therefore never get to healthy nutrition.
The simplest OOP concept is inheritance and you see the biggest advantage when you see that changing one base class property like FontName or FontSize changes all child classes and objects of child classes you put onto a form, too. So you can, for example, centralize some very basic settings to only do them once or a few times only at least - as VFP, unfortunately, has a caption property on multiple base classes, and they don't inherit from a central font base class. But you get the idea.
Only seeing that working inspires learning more about this "magic" of reusability.
Just a simple example: Have one onscreenkey class, add a property "focusedcontrol" and this code
Code:
* onscreenkey When() event
Try
This.focusedcontrol = Thisform.Activecontrol
Catch
This.focusedcontrol = .NULL.
Endtry
Code:
* onscreenkey Click() event
If NOT IsNull(This.focusedcontrol)
This.focusedcontrol.SetFocus()
Keyboard (This.Caption)
EndifThis will cover most of the keys on an onscreen keyboard (eg for tablet devices used via touch interface when users don't have a mouse or keyboard attached, as in a POS station)
You don't need this code in ~100 buttons on a form or container, you just need to change the caption so the button code causes the same as a real keyboard key with that caption.
And if you want to add behavior like acting with CAPSLOCK or SHIFT (virtual SHIFT) pressed at the same time, then it's sufficient to do that in the one onscreenkey class. You might want to subclass letter keys to make use of UPPER(This.Caption), whereas that doesn't work for numeric keys in row 1 of a keyboard, so there you also have a motivation to do that. And it's all not very complicated code.
This would be some small exercise to start with and finish as an on-screen keyboard.
That said, specifically about this there's something on board of the Windows system, called OSK.exe and Yousfi Benameur wrote about how to make use of that: so forget about saying this all works easier when you design buttons for a toolbar, which doesn't remove the focus in the first place, indeed this has so much details that you better make use of a system component. It's still a nice exercise to use for learning something. A nice example of how you only write something once you use 100 times. You can even spare to manually design 100 keys when you let a loop create the key button objects. fed by the metadata of keyboard layout coming from a string like "QWERTYUIOP" (just as a hint).
The more you want to be able to learn AND also use what you created in your exercising of OOP, the more I would NOT go a route of fast progress in the sense of doing something that lets you see fast results. You'll need to be willing to throw away things you create as exercise anyway, but it doesn't have to be everything you first do in the darkness about some concepts that first don't seem appealing and beneficial.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #14
Thanks everyone.
I am getting lot of information. I have to agree that some are far beyond my understanding, but please don't stop.
I have checked Tamar's guide, Olaf's links. Everything is interesting and I am trying everything.
So far I learnt a little to create a form, placing some textboxes, combo boxes, checkboxes and buttons. The properties of some controls are little confusing for me, like 'DisplayValue' and 'Text' for combo boxes. I get confused which one to use. Similarly, whether to use the 'Text' or 'Value' property of a textbox and so on.
On the events side, I am confused whether to use 'InteractiveChange' or 'Click' when it comes to combo boxes. I am trying one by one and learning.
Any information from anyone would be helpful. Thank you guys.
-------------
Looking for knowledge from anyone, anywhere.
I am getting lot of information. I have to agree that some are far beyond my understanding, but please don't stop.
I have checked Tamar's guide, Olaf's links. Everything is interesting and I am trying everything.
So far I learnt a little to create a form, placing some textboxes, combo boxes, checkboxes and buttons. The properties of some controls are little confusing for me, like 'DisplayValue' and 'Text' for combo boxes. I get confused which one to use. Similarly, whether to use the 'Text' or 'Value' property of a textbox and so on.
On the events side, I am confused whether to use 'InteractiveChange' or 'Click' when it comes to combo boxes. I am trying one by one and learning.
Any information from anyone would be helpful. Thank you guys.
-------------
Looking for knowledge from anyone, anywhere.
-
1
- #15
On a combobox, the DisplayValue can be different to the Value.
The Value, read back to a variable or field, will normally exist in the list of combo items or be blank (empty).
The DisplayValue could be something else though - because it might have been typed by a user... that's my take on it anyway!
Regards
Griff
Keep [Smile]ing
The Value, read back to a variable or field, will normally exist in the list of combo items or be blank (empty).
The DisplayValue could be something else though - because it might have been typed by a user... that's my take on it anyway!
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
-
1
- #16
Mike Lewis
Programmer
Regarding the difference between the Text and Value properties ....
Value is the one that you will use most often. It contains the actual value of the control, in the appropriate data type. By contrast, Text contains the same value but represented as a character string. So, if you have a textbox that contains the number 100, then Value will contain that number (with a numeric data type), but Text will contain "100", that is 100 as a string.
The above applies mainly to textboxes, editboxes and spinners. With a combobox, the Value is the value of the selected item, and is always a character string (comboboxes and listboxes only contain character data).
The DisplayValue (of a combobox) is usually used when the Style property is 0. This means that the user can type new values as well as picking values from a list. It works as follows:
- If the user picks a value from the list:
Value contains the selected value (and if the list has multiple columns, it is the value in the BoundColumn)
DisplayValue contains the value of the selected item in column 1.
- If the user types a new value:
Value is empty
DisplayValue contains whatever the user types.
I have slightly over-simplified the above explanation, but it should be enough to get you started.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Value is the one that you will use most often. It contains the actual value of the control, in the appropriate data type. By contrast, Text contains the same value but represented as a character string. So, if you have a textbox that contains the number 100, then Value will contain that number (with a numeric data type), but Text will contain "100", that is 100 as a string.
The above applies mainly to textboxes, editboxes and spinners. With a combobox, the Value is the value of the selected item, and is always a character string (comboboxes and listboxes only contain character data).
The DisplayValue (of a combobox) is usually used when the Style property is 0. This means that the user can type new values as well as picking values from a list. It works as follows:
- If the user picks a value from the list:
Value contains the selected value (and if the list has multiple columns, it is the value in the BoundColumn)
DisplayValue contains the value of the selected item in column 1.
- If the user types a new value:
Value is empty
DisplayValue contains whatever the user types.
I have slightly over-simplified the above explanation, but it should be enough to get you started.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #17
Olaf Doschke
Programmer
The most important properties of controls are controlling the data binding. And that is controlsource for most controls, including listbox and combobox. Unlike textboxes, editboxes, options, checkboxes and spinners (and whatever I forgot) they have further binding properties because while the general purpose of data binding is to bind to a single field and store a single value, in listboxes and comboboxes this single value will be picked from a list, and so the secondary binding property - the rowsource - is about the list of items to pick from.
I don't know if you're well versed with data normalization, but this mechanism is aiming for that, the best use case is binding to the primary key of a list of data, to pick one of them and store it as a foreign key. This is where VFP data binding goes hand in hand with database normalization.
The third and even more versatile list control is the grid, it does not only compare to, but it is the core of a browse window. It does not have a controlsource at all, it only has a property determining the list of data to display, and that'll usually be a workarea which contains a table, cursor, viewcursor, well you know that because that concept should be well known from legacy FoxPro. The grid does not have a single controlsource, because that is the job of the control the grid hosts, one per column, usually a textbox. You know that from a BROWSE, too, the cells of a browse display the fields of a dbf as a textbox does. Including very specific behavior like not displaying memo content, but instead, the word memo or Memo, depending on whether data is in the field. For certain field types you want to change from a textbox to another control, but that's the topic of another chapter.
What I want to say with this is the chapter of data binding of controls is the most important, because it makes thinking of Value vs. Text vs. DisplayValue almost obsolete, once. The values you enter into textbox/editbox or pick in a listbox/combobox go into the controlsource fields and that's where your code picks them up again. Mike is still right the Value property is most important, because it holds the value to store, before it is stored in the valid event. And that's where you can go back to what I said about event order, the valid is also where you decide, whether the entered value should be accepted or rejected.
It's even less pain of knowing the details, though, as data binding takes care your data types are correct, if you bind a textbox.controlsource to a numeric field, the textbox will not accept input of text, for example, so data type checks are not your concern, the controlsource really is a two-way binding of data from and to dbf fields.
If you then add in binding, you rarely need any valid event code at all, you can have a final data rule check routine before you save the buffer or ask the user to enter mandatory values or stay within business rules in the general case. Like having a start date earlier than an end-date. This is a check you can only really do after both dates are entered. Just one of many reasons you don't want to fiddle with all the details and finally work on what you should still know from legacy coding: The workareas, current workareas, current row, but also, if a business rule check requires it, a group of rows, like all n child/detail rows pointing to the same parent row. That's something you can forget to check on a single control anyway.
So, to summarize, once you learn data binding and buffering - and that's a lot - you have a few benefits and less to care about control properties, more about dbfs/workareas/cursors fields, about SQL and/or LOCATE/SEEK, etc., the forms just are means to change your tables, finally the data is all you process.
The properties of the visual controls of interest right after data binding properties then are those determining behavior of controls while you input data, like Format and InputMask of the textbox.
Also, as a very general rule: Look up a property in the help, it'll tell you as one of the first sentences, whether it's a readonly property or not. A readonly property obviously is not for setting it, so it has an informative character.
Just as a little start help: Create an SCX form, use the data environment to add a dbf, when you're in the visual dataenvironment and drag a field into the form canvas, you will get a control with data binding to that field, so you can study how that's set. Especially using the properties window set to only display non-default properties only (right click on the top combobox in the properties window.
Bye, Olaf.
Olaf Doschke Software Engineering
I don't know if you're well versed with data normalization, but this mechanism is aiming for that, the best use case is binding to the primary key of a list of data, to pick one of them and store it as a foreign key. This is where VFP data binding goes hand in hand with database normalization.
The third and even more versatile list control is the grid, it does not only compare to, but it is the core of a browse window. It does not have a controlsource at all, it only has a property determining the list of data to display, and that'll usually be a workarea which contains a table, cursor, viewcursor, well you know that because that concept should be well known from legacy FoxPro. The grid does not have a single controlsource, because that is the job of the control the grid hosts, one per column, usually a textbox. You know that from a BROWSE, too, the cells of a browse display the fields of a dbf as a textbox does. Including very specific behavior like not displaying memo content, but instead, the word memo or Memo, depending on whether data is in the field. For certain field types you want to change from a textbox to another control, but that's the topic of another chapter.
What I want to say with this is the chapter of data binding of controls is the most important, because it makes thinking of Value vs. Text vs. DisplayValue almost obsolete, once. The values you enter into textbox/editbox or pick in a listbox/combobox go into the controlsource fields and that's where your code picks them up again. Mike is still right the Value property is most important, because it holds the value to store, before it is stored in the valid event. And that's where you can go back to what I said about event order, the valid is also where you decide, whether the entered value should be accepted or rejected.
It's even less pain of knowing the details, though, as data binding takes care your data types are correct, if you bind a textbox.controlsource to a numeric field, the textbox will not accept input of text, for example, so data type checks are not your concern, the controlsource really is a two-way binding of data from and to dbf fields.
If you then add in binding, you rarely need any valid event code at all, you can have a final data rule check routine before you save the buffer or ask the user to enter mandatory values or stay within business rules in the general case. Like having a start date earlier than an end-date. This is a check you can only really do after both dates are entered. Just one of many reasons you don't want to fiddle with all the details and finally work on what you should still know from legacy coding: The workareas, current workareas, current row, but also, if a business rule check requires it, a group of rows, like all n child/detail rows pointing to the same parent row. That's something you can forget to check on a single control anyway.
So, to summarize, once you learn data binding and buffering - and that's a lot - you have a few benefits and less to care about control properties, more about dbfs/workareas/cursors fields, about SQL and/or LOCATE/SEEK, etc., the forms just are means to change your tables, finally the data is all you process.
The properties of the visual controls of interest right after data binding properties then are those determining behavior of controls while you input data, like Format and InputMask of the textbox.
Also, as a very general rule: Look up a property in the help, it'll tell you as one of the first sentences, whether it's a readonly property or not. A readonly property obviously is not for setting it, so it has an informative character.
Just as a little start help: Create an SCX form, use the data environment to add a dbf, when you're in the visual dataenvironment and drag a field into the form canvas, you will get a control with data binding to that field, so you can study how that's set. Especially using the properties window set to only display non-default properties only (right click on the top combobox in the properties window.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
- Locked
- Question