bBrowser and getting a value to set a filter with
in [Visual Objects]
|
Prev: Simple email sample
Next: Graphics4VO to vulcan
From: Grant on 3 Nov 2009 15:28 On Nov 3, 1:18 am, "Stephen Quinn" <stevej...(a)bigpondSPAM.net.au> wrote: > Grant > > Forgot to mention that the child database MUST have an index for the > relationship to work, the link field doesn't have to be part of the index > expression though. > Eg > INDEX ON CUSTID + JOBNO TAG JOBNOORDER > INDEX ON CUSTID + DTOS( DATEFFLD ) TAG JOBNOORDER > > That way the relationship on CUSTID will still show the Jobs in numerical > order or date order if you have the appropriate index defined. > > CYA > Steve Thanks for the info on setting relationships but I am still stumped at an issue that I need to resolve to stay sane. It is the DoubleClick() method which I have rewritten to go to the 2nd or Job browser. Within the 1st browser I have acess to the data fields but when I run the DoubleClick the focus is away from the original DBServer object even though the pointer in the DBF file remains where it should be. I can no longer access the fields from the previous local dbserver object and if I create another server the record position lost. Should I be creating a global server object or ??? How do I get into the DoubleClick method and still have the record number or field value that the cursor was on when the double click event occurred? The solution is probably fairly obvious but I can't see it right now. Regarding VO upgrading. I almost did it a year or so ago but I will have to now very soon. Thanks for the advice. Grant
From: Geoff Schaller on 3 Nov 2009 16:24 Grant, There is no "local" dbserver object at all. You have two browsers and each browser has a server. Yes? So now in one browser you double click a cell and the CellDoubleClick method in the window is fired with an event passed as a parameter (check the bBrowser manual). Right, so now you can do this in that method: Local oClickedBrowser as bBrowser oClickedBrowser := oEvent:Control if oClickedBrowser = SELF:oDCFirstBrowser // can use Self:oDCFirstBrowser:Server Else // can use SELF:oDCOtherBrowser:Server Endif Of course I would then assign servers to strongly typed ivars but you have access to the browser object (to read current column and row) and the server (to read row values). Geoff "Grant" <grantd(a)dunsmoreinfo.com> wrote in message news:f110aa69-885d-41f4-b901-d1b16bf2e29d(a)k4g2000yqb.googlegroups.com: > On Nov 3, 1:18 am, "Stephen Quinn" <stevej...(a)bigpondSPAM.net.au> > wrote: > > > Grant > > > > Forgot to mention that the child database MUST have an index for the > > relationship to work, the link field doesn't have to be part of the index > > expression though. > > Eg > > INDEX ON CUSTID + JOBNO TAG JOBNOORDER > > INDEX ON CUSTID + DTOS( DATEFFLD ) TAG JOBNOORDER > > > > That way the relationship on CUSTID will still show the Jobs in numerical > > order or date order if you have the appropriate index defined. > > > > CYA > > Steve > > > Thanks for the info on setting relationships but I am still stumped at > an issue that I need to resolve to stay sane. It is the DoubleClick() > method which I have rewritten to go to the 2nd or Job browser. Within > the 1st browser I have acess to the data fields but when I run the > DoubleClick the focus is away from the original DBServer object even > though the pointer in the DBF file remains where it should be. I can > no longer access the fields from the previous local dbserver object > and if I create another server the record position lost. Should I be > creating a global server object or ??? How do I get into the > DoubleClick method and still have the record number or field value > that the cursor was on when the double click event occurred? The > solution is probably fairly obvious but I can't see it right now. > Regarding VO upgrading. I almost did it a year or so ago but I will > have to now very soon. Thanks for the advice. > Grant
From: Stephen Quinn on 3 Nov 2009 20:02 Grant METHOD CellDoubleClick( oEvent ) CLASS MyWindow LOCAL oControl AS CONTROL oControl := oEvent:Control DO CASE CASE oControl:Hyperlabel:NameSym = #BBPARENT cFName := oControl:Server:Fieldget( #FNAME ) CASE oControl:Hyperlabel:NameSym = #BBCHILD ENDCASE Think about GLOBALS like you would about FILTERS - avoid wherever possible and if you 'think' you must use them re-think what your trying to do Don't get me wrong they have a place - in HISTORY (and other peoples code) and that's where they should stay<bg> It'd be a lot easier if you posted the CODE (10-20 lines) that you've tried using so we can point you in the right direction. We can all read code but sometimes have problems understanding/interpreting the written explanation. I suggest you read the bBrowser docs re: bBrowser:CellDoublecClick() and it's other CALLBACK accomplices CYA Steve
From: Grant on 4 Nov 2009 01:30 On Nov 3, 5:02 pm, "Stephen Quinn" <stevej...(a)bigpondSPAM.net.au> wrote: > Grant > > METHOD CellDoubleClick( oEvent ) CLASS MyWindow > > LOCAL oControl AS CONTROL > > oControl := oEvent:Control > > DO CASE > CASE oControl:Hyperlabel:NameSym = #BBPARENT > cFName := oControl:Server:Fieldget( #FNAME ) > > CASE oControl:Hyperlabel:NameSym = #BBCHILD > ENDCASE > > Think about GLOBALS like you would about FILTERS > - avoid wherever possible and if you 'think' you must use them re-think > what your trying to do > > Don't get me wrong they have a place > - in HISTORY (and other peoples code) and that's where they should > stay<bg> > > It'd be a lot easier if you posted the CODE (10-20 lines) that you've tried > using so we can point you in the right direction. > We can all read code but sometimes have problems understanding/interpreting > the written explanation. > > I suggest you read the bBrowser docs > re: bBrowser:CellDoublecClick() > and it's other CALLBACK accomplices > > CYA > Steve I was getting desperate when I asked about Global variables. Thank you to Geoff for his comments about proper use of the controlevent parameter. I was able to extract the field from the chosen record of the Customer data file by rewriting my CellDoubleClick method. Now I am able to access the field data as a string and was going to use this to set a filter. If there is abetter way please let me know. Here are the lines of code first to creat the first browser and then the CellDoubleClick callback method to get the desired customer field for the next browser : Method bBrowser_Customer class Shell LOCAL odtwBrowser AS dtwBrowser LOCAL odbsServer AS DBServer odbsServer := bDServer{"C:\CompanyFolder\Customer.dbf",,, GetRdd("C:\CompanyFolder\Customer.dbf")} odtw := dtwBrowser{SELF} odtwBrowser:Show() odtwBrowser:Use(odbsServer) and Method CellDoubleClick(oControlEvent) CLASS dtwBrowser LOCAL oBrowser AS JobWin LOCAL oCustBrowser as dtwBrowser LOCAL cFName AS USUAL LOCAL cFilter AS STRING LOCAL oControl := oControlEvent:Control cFilter := NULL_STRING oCustBrowser := oControEvent:Control cFName := oCustBrowser:Server:FieldGet(2) cFilter := cFName oBrowser := JobWin{SELF:Owner,,,{SELF,TRUE}} Works down to here. If I comment out the next 2 lines I get the second browser screen but contains all the records. oBrowser:SetFilter( cFilter ) Something wrong here oBrowser:GoTop oBrowser:Show() Does this make sense? Would you not use a filter here? I'm trying to bend my head around using relationships but I'm a little lost. I want to pick a customer and then open a browser with a list of jobs done for that one customer and be able to edit, print, or create new jobs in this bbrowser screen. Thanks for your help Grant
From: Geoff Schaller on 4 Nov 2009 02:09
No, not a filter. A scope. Create an index on the expression you wish to filter and set a top and bottom scope. Far, far more efficient than a filter and a zillion times faster. Geoff "Grant" <grantd(a)dunsmoreinfo.com> wrote in message news:5612968e-e75d-4e0a-97cd-caf22dfe13b4(a)j24g2000yqa.googlegroups.com: > On Nov 3, 5:02 pm, "Stephen Quinn" <stevej...(a)bigpondSPAM.net.au> > wrote: > > > Grant > > > > METHOD CellDoubleClick( oEvent ) CLASS MyWindow > > > > LOCAL oControl AS CONTROL > > > > oControl := oEvent:Control > > > > DO CASE > > CASE oControl:Hyperlabel:NameSym = #BBPARENT > > cFName := oControl:Server:Fieldget( #FNAME ) > > > > CASE oControl:Hyperlabel:NameSym = #BBCHILD > > ENDCASE > > > > Think about GLOBALS like you would about FILTERS > > - avoid wherever possible and if you 'think' you must use them re-think > > what your trying to do > > > > Don't get me wrong they have a place > > - in HISTORY (and other peoples code) and that's where they should > > stay<bg> > > > > It'd be a lot easier if you posted the CODE (10-20 lines) that you've tried > > using so we can point you in the right direction. > > We can all read code but sometimes have problems understanding/interpreting > > the written explanation. > > > > I suggest you read the bBrowser docs > > re: bBrowser:CellDoublecClick() > > and it's other CALLBACK accomplices > > > > CYA > > Steve > > > I was getting desperate when I asked about Global variables. Thank you > to Geoff for his comments about proper use of the controlevent > parameter. I was able to extract the field from the chosen record of > the Customer data file by rewriting my CellDoubleClick method. Now I > am able to access the field data as a string and was going to use this > to set a filter. If there is abetter way please let me know. Here are > the lines of code first to creat the first browser and then the > CellDoubleClick callback method to get the desired customer field for > the next browser : > > Method bBrowser_Customer class Shell > LOCAL odtwBrowser AS dtwBrowser > LOCAL odbsServer AS DBServer > odbsServer := bDServer{"C:\CompanyFolder\Customer.dbf",,, > GetRdd("C:\CompanyFolder\Customer.dbf")} > odtw := dtwBrowser{SELF} > odtwBrowser:Show() > odtwBrowser:Use(odbsServer) > and > Method CellDoubleClick(oControlEvent) CLASS dtwBrowser > LOCAL oBrowser AS JobWin > LOCAL oCustBrowser as dtwBrowser > LOCAL cFName AS USUAL > LOCAL cFilter AS STRING > LOCAL oControl := oControlEvent:Control > > cFilter := NULL_STRING > oCustBrowser := oControEvent:Control > cFName := oCustBrowser:Server:FieldGet(2) > cFilter := cFName > > oBrowser := JobWin{SELF:Owner,,,{SELF,TRUE}} > Works down to here. If I comment out the next 2 lines I get the second > browser screen but contains all the records. > oBrowser:SetFilter( cFilter ) > Something wrong here > oBrowser:GoTop > oBrowser:Show() > > Does this make sense? Would you not use a filter here? I'm trying to > bend my head around using relationships but I'm a little lost. I want > to pick a customer and then open a browser with a list of jobs done > for that one customer and be able to edit, print, or create new jobs > in this bbrowser screen. > > Thanks for your help > Grant |