Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Where do I requery?
Message
From
04/04/2002 17:11:08
 
 
To
04/04/2002 14:59:51
General information
Forum:
Visual FoxPro
Category:
CodeMine
Miscellaneous
Thread ID:
00639024
Message ID:
00641137
Views:
20
>and that the overt manipulation of the form from the CDE really requires too much user knowledge (is that clear?).

I dont know about too much user knowledge <s> but it is fair to say that it is a good idea to have a reasonable understanding of the CDE to use it to its best, so to speak. I think it is fairly obvious when you are using a CDE with a form and as such, you can then make a decision as to whether it is reasonable to directly access the form from the CDE. Personally, I think it is if you know that this instance of a CDE is for form use. If it wasn't intended this way, Dave wouldn't have provided the oForm property to test for existance of a form.

>I was wondering if the cmDatamanager class was to act as an intermediary between the form and the CDE.

I don't think that there is any point in subclassing the datamanager anymore - you do that stuff in the CDE. I also feel that the the datamanager is a one way link to the CDE - from the form. If you are in a form and you wish to routinely call DE and cursor based methods, you can do it via the datamanager. However, this is IMHO mostly to maintain backward compatability with earlier versions of Codemine. If you removed the datamanager, all the old CM apps would break, if you were starting out with CM7, you could pretty much do without the datamanager.

-=Gary




>>Hi Michael:
>>
>>Its one of those situations where you know you are using the CDE with a form, as Denis implied. You are testing for the existance of a form using something like :-
>>
>>
>>If not isnull(this.oForm)
>>
>>
>>If there is no form object available, you dont do the stuff that accesses the form.
>>
>>The datamanager nowadays is primarily for interaction between form and CDE.
>>
>>Irrespective, I am having great fun with the CDE and, using the CDE wrapped with a prog based class and putting any custom methods/properties in the prog class.
>>
>>I am also creating CDE based encapsulated objects that can be called from batch routines, non-form based code and form based useage. They are a great improvement on what was available in V6. The Codemine CDE is a very exciting part of V7.
>>
>>-=Gary
>>
>>
>>
>>>I wonder about this. Though I might use it, I would prefer that the CDE knew as little as possible about the form that was using it. To me it seems to violate the encapsulation of the CDE. Maybe the forms cmdatamanager would be a better place to put this since its contained in the form.
>>>
>>>>Using the form's load event is really not the appropriate thing to do when using CM7. OK, it works but the idea is separating the data aspect(s) from the form. I presume that you are opening the view in the load method too?
>>>>
>>>>The keep the clean separation maybe the best thing to do is to set the row source/value of the control to nothing (no value) in the form at design time. Then, when the controls are instantiating before the form's init fires, the control currently bound to the view will not complain because it has no row source/value set.
>>>>
>>>>Then, in the CDE's AfterOpenAll event, you can requery the view and then use :-
>>>>
>>>>this.oForm.ControlName.RowsourceType = 2
>>>>
>>>>and so on, to set the view as the control source after the controls have instantiated.
>>>>
>>>>In this way, you can keep all of your data handling in the CDE and leave the form's native events alone.
>>>>
>>>>>I tried putting it in the AfterOpenAll but it was too late. So I ended up
>>>>>putting it in the LOAD method of the form.
>>>>>
>>>>>>Denis:
>>>>>>
>>>>>>OK. I see where you are coming from with this. I presume that the value for the parameter is available/known before the form instantiates. If so, I would do this in CDE.AfterOpenAll().
>>>>>>
>>>>>>Just to recap, I assume that you have the view specified in the CDE and it is set to "no data on load". In the AfterOpenAll event method, get a reference to the cursor object like so.
>>>>>>
>>>>>>local oMyView
>>>>>>oMyView = this.getcursor('MyViewName') && Where this is the CDE object.
>>>>>>oMyView.requery('parametervalue')
>>>>>>
>>>>>>This should do it for you.
>>>>>>
>>>>>>HTH
>>>>>>
>>>>>>-=Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Gary
>>>>>>>
>>>>>>>What I want to do is this. Use a view with a parameter so I can filter some
>>>>>>>data that will appear in a combobox. So when I init the form I want the
>>>>>>>data to be there. That's why I need to define the parameter and requery
>>>>>>>the view somewhere in the CDE.
>>>>>>>
>>>>>>>later on in the form I'll be able to requery depending on what the user
>>>>>>>selected from another combobox.
>>>>>>>
>>>>>>>Do you know where the best places to do this are?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Denis:
>>>>>>>>
>>>>>>>>What you are trying to do is essentially call the cursor class's requery method. Obviously, you can call the requery method from anywhere you like; from the form via the datamanager or from within the CDE itself.
>>>>>>>>
>>>>>>>>However, there is generally no need to manually requery a parameterised view as this is handled by Codemine automatically.
>>>>>>>>
>>>>>>>>If you go into the builder for a cursor object and look at the RI (referential integrity) section, you can tick the box that say's "automatically requery cursor when parent moves" (or words to that effect). So, as long as you have set the relational parameters correctly for the cursor (again in the builder) ie., specified the primary and foreign key fields for the cursor, the requerying is, for all intent and purposes, automatically handled for you by the framework.
>>>>>>>>
>>>>>>>>When the cursor is based on a parameterised view, Codemine automatically assigns the parent value (as specified by you in the cursor properties) to the view's parameter variable (as specified in the view definition). If the cursor is a table it uses native SET RELATION TO or SET KEY TO logic. So, irrespective of the cursor type, as long as you specify the primary/foreign key field values (and set the cursor's order where appropriate), you don't have to worry about requerying a parameterised view.
>>>>>>>>
>>>>>>>>HTH
>>>>>>>>
>>>>>>>>-=Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>>CodeMine 7.0 RC2
>>>>>>>>>
>>>>>>>>>In the CDE what would be the best place to requery a parameterized view?
>>>>>>>>>
>>>>>>>>>I want to get all the record so the CDE should be the best place to do this
>>>>>>>>>requery.
>>>>>>>>>
>>>>>>>>>It not the CDE would it be better in cmRule or cmCursor?
-=Gary
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform