Page 1 of 1
VALID not firing if WHEN is used
Posted: Thu Nov 14, 2013 12:09 am
by Andy Edward
Hi,
I know that VALID will fire before the focus goes to the next object, and WHEN is to decide whether the DCGET greyed out or not.
Code: Select all
@1,71 DCGET MREFNO popup {|c| c:=GETREFNO(COM_TYPE,aLocals,' '),;
EVAL ({|c| SEEK_ORDER(c,COM_TYPE,xARRAY,aLocals,xNEWARRAY,bTASK),DC_GETREFRESH(GETLIST)},c),c};
VALID {|x| x:=SEEK_ORDER(MREFNO,COM_TYPE,xARRAY,aLocals,xNEWARRAY,bTASK),DC_GETREFRESH(GETLIST),x };
WHEN {|| .F. } LOSTFOCUS BREFRESH GETSIZE 9.8 PICTURE '@!' COLOR MGETCOLOR1,MGETCOLOR2
@2,71 DCGET MCHEQUE PICTURE '@!' COLOR MGETCOLOR1,MGETCOLOR2;
VALID {|x| OLDCHQ:=MREFNO,x:=CA_DUPCHQ(OLDCHQ,xARRAY,xNEWARRAY,COM_TYPE,aLocals),dc_getrefresh(getlist),x} GETSIZE 12;
WHEN {|| EMPTY(MCHEQUE) .OR. COM_TYPE = '3' }
But at my code above, the problem lies on the second DCGET @2,71. If I purposely leave the MCHEQUE empty, and press enter, the CA_DUPCHQ function will run.
But if I input something to MCHEQUE, CA_DUPCHQ will not run and the focus will automatically move to the next object. I've already put msgboxes inside CA_DUPCHQ, but those msgboxes never appear.
Strange part for me is that, if I remove the WHEN on the second DCGET,
Code: Select all
@2,71 DCGET MCHEQUE PICTURE '@!' COLOR MGETCOLOR1,MGETCOLOR2;
VALID {|x| OLDCHQ:=MREFNO,x:=CA_DUPCHQ(OLDCHQ,xARRAY,xNEWARRAY,COM_TYPE,aLocals),dc_getrefresh(getlist),x} GETSIZE 12
the CA_DUPCHQ will run every time as intended.
Anyone else have this issue? or is it just my understanding of VALID and WHEN that is wrong?
Regards,
Andy
Re: VALID not firing if WHEN is used
Posted: Thu Nov 14, 2013 1:14 am
by skiman
HI,
The valid of your second get will never be executed if the get is not active.
So if your first get remains empty, the second get isn't active, you can't enter data, and there is no reason to validate.
Re: VALID not firing if WHEN is used
Posted: Thu Nov 14, 2013 1:40 am
by Andy Edward
skiman wrote:HI,
The valid of your second get will never be executed if the get is not active.
So if your first get remains empty, the second get isn't active, you can't enter data, and there is no reason to validate.
The second GET is active / not grayed out when the first time the form is generated. Also the WHEN in the second GET is referring the parent (SECOND) GET, not the first GET
@2,71 DCGET MCHEQUE PICTURE '@!' COLOR MGETCOLOR1,MGETCOLOR2;
VALID {|x| OLDCHQ:=MREFNO,x:=CA_DUPCHQ(OLDCHQ,xARRAY,xNEWARRAY,COM_TYPE,aLocals),dc_getrefresh(getlist),x} GETSIZE 12;
WHEN {|| EMPTY(MCHEQUE) .OR. COM_TYPE = '3' }
So it doesn't rely on the first GET to be active, it relies on itself.
Regards,
Andy
Re: VALID not firing if WHEN is used
Posted: Thu Nov 14, 2013 2:30 pm
by Cliff Wiernik
I think the issue is the WHEN. When you leave it blank and press enter, the when is .T. and the valid is called. However, if you fill in value, the WHEN was true prior to completion of the GET, but is FALSE as soon as the GET is filled. I think Roger's code does not attempt validation of the GET when the WHEN is .F., which it is when you put something into the GET. The WHEN clause is also processed first and buy the windows system first, so its value/state is changed prior to the determination of whether the VALID clause should be evaluated.
As a matter of principal, I do not use the WHEN clause for 2 reasons: (1) - it grays out the field value and (2) it cannot be defined for a dialog via DCGETOPTIONS. I use the EDITPROTECT features instead and instead of graying out the field value, change the background to GRA_CLR_BACKGROUND.
Re: VALID not firing if WHEN is used
Posted: Thu Nov 14, 2013 6:44 pm
by Andy Edward
Cliff Wiernik wrote:
The WHEN clause is also processed first and buy the windows system first, so its value/state is changed prior to the determination of whether the VALID clause should be evaluated.
Is it a new implementation where the WHEN clause is processed first? I have two exactly the same applications where one is using Express++ 1.9 and Express++ 1.82.
I'm using the 1.9 and I saw this behavior, but not in 1.82 ( I know it's old, but it is still the one that we are selling. At least we are trying to move forward)
Also, I thought WHEN and VALID are two independent clause. So if WHEN returns .F., VALID will still run because there is no dependence to WHEN clause.
Did something changed along the way from Express++ 1.82 to 1.9, regarding how WHEN clause is processed?
Best Regards,
Andy
Re: VALID not firing if WHEN is used
Posted: Fri Nov 15, 2013 7:47 am
by skiman
Hi,
Maybe the following will work:
Code: Select all
Local lEmptyCheck := .T.
...
@2,71 DCGET MCHEQUE PICTURE '@!' COLOR MGETCOLOR1,MGETCOLOR2;
VALID {|x| OLDCHQ:=MREFNO,x:=CA_DUPCHQ(OLDCHQ,xARRAY,xNEWARRAY,COM_TYPE,aLocals),lEmptyCheque:=empty(mCheque),dc_getrefresh(getlist),x} GETSIZE 12;
WHEN {|| lEmptyCheck .OR. COM_TYPE = '3' }
Re: VALID not firing if WHEN is used
Posted: Fri Nov 15, 2013 9:40 am
by Cliff Wiernik
I am not certain exactly on the specifics of timing of the WHEN clause in Express. I think that WHEN translates into the enable/disable object method(). I have found that enable()/disable() does not require a getrefresh to be specified whereas editprotect and other Express++ enhancement require the getrefresh to be processed. Thus, this is why I recall seeing WHEN taking priority. In the express readme, item 733 talks about a bug fix/regression, but I think it may be related to this issue.
Roger should be able to be definitive on this topic.
Re: VALID not firing if WHEN is used
Posted: Fri Nov 15, 2013 3:17 pm
by rdonnay
Roger should be able to be definitive on this topic.
There's no way I am going to change eXpress++ code again to deal with issues like this that are obscure. If everyone were complaining about it, I would do something, but I haven't heard of a problem like this in years.
If you will give me a small app that demonstrates the problem, I will try to give you a workaround.
Re: VALID not firing if WHEN is used
Posted: Fri Nov 15, 2013 3:30 pm
by Cliff Wiernik
I'm not recommending any changes. I think it works correctly as I would expect it. I have no problems with behavior. Been there before, don't want to go back.