Page 1 of 1

DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 5:21 am
by skiman
Hi,

I have a lot of GET's with a valid. This is working without any problem. I'm looking to my sources to optimize the speed of my application. I see that the VALID codeblock is always executed, even when there is nothing changed in the GET. This is normal behaviour and is fine in most cases.

However, in some cases the VALID is doing a lot of unnecessary things if the GET isn't changed.

I take ... GET cCustomer VALID {|oGet| seekcustomer(..) } as an example.
The VALID block with seekcustomer is opening a table, searching the value, ... which takes some time. If cCustomer isn't changed, there is no need to do all this.

What would be the best way to avoid this?
Changing the codeblock as follows seems to work, but I'm wondering if there is a better way?
VALID {|oGet| iif(!empty(oGet:buffer) .and.oGet:buffer==oGet:undobuffer,.T.,seekcustomer(...)) }

The change in speed is minor, but when there are 40 users working, the change can make a difference.

Re: DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 6:09 am
by rdonnay
Let me look into this.

There is probably something I can do in eXpress++.

Here's an update.

DC_GetValidate() has been reworked a lot over the years.
There is even a get-set function call DC_GetValidateOnChange() however this affects all validations.

I think that your workaround is the best solution, because a global solution may give undesired results.

Re: DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 6:13 am
by skiman
Hi Roger,

In some cases the VALID codeblock MUST always be executed, even if there is nothing changed!

Re: DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 6:22 am
by rdonnay
DC_GetValidate() has been reworked a lot over the years.
There is even a get-set function call DC_GetValidateOnChange() however this affects all validations.

I think that your workaround is the best solution, because a global solution may give undesired results.

Re: DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 6:34 am
by skiman
Roger,

There is XbpSLE:changed, but it looks as the DCGET isn't a subclass of XbpSle?

XbpSLE also has :cuebanner. Is there any way to do this with eXpress++?

Re: DCSAY... GET .... VALID ... question

Posted: Thu Apr 07, 2022 6:42 am
by skiman
Hi Roger,

By checking your code for the implementation of your DC_GetValidateOnChange(), I found the answer.
VALID {|oGet| iif(oGet:get:changed,seekcustomer(...),.T.) }

This looks as an easy way to decide wether or not the valid must be executed.

Re: DCSAY... GET .... VALID ... question

Posted: Fri Apr 08, 2022 6:35 am
by skiman
Hi,

According to my code the DC_GetValidateOnChange() is checking the value oGet:get:changed to decide if the value in a GET is changed.

If there is a POPUP for the GET which changes the GET value, the var oGet:get:changed remains FALSE.

So it won't validate with the new value!

Re: DCSAY... GET .... VALID ... question

Posted: Tue Apr 12, 2022 5:43 am
by rdonnay
Sorry, I got so busy the past few days that I haven't been following this thread.

What is it that you want me to do?

Can you write me a small snippet of code that demonstrates your problem?

Re: DCSAY... GET .... VALID ... question

Posted: Tue Apr 12, 2022 6:06 am
by skiman
Hi Roger,

I don't expect that you change anything for this. My original question was how to avoid the execution of a VALID when there is nothing changed. I thought there would be an easy way to accomplish this.

Meanwhile I have a solution for this, in combination with the POPUP which is also executing the VALID..

When the popup is used, the VALID is executed only once. If nothing is changed, the VALID isn't executed. I'm using :cargo to get the result I want. With GETEVAL I set the :cargo at start.

This way the VALID is only executed ONCE after a change of the GET. I expect this will reduce the network traffic when there are a lot of users.

Re: DCSAY... GET .... VALID ... question

Posted: Tue Apr 12, 2022 10:09 am
by rdonnay
Ok, thanks. I'm glad you found a solution.