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.
DCSAY... GET .... VALID ... question
Re: DCSAY... GET .... VALID ... question
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.
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.
The eXpress train is coming - and it has more cars.
Re: DCSAY... GET .... VALID ... question
Hi Roger,
In some cases the VALID codeblock MUST always be executed, even if there is nothing changed!
In some cases the VALID codeblock MUST always be executed, even if there is nothing changed!
Re: DCSAY... GET .... VALID ... question
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.
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.
The eXpress train is coming - and it has more cars.
Re: DCSAY... GET .... VALID ... question
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++?
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
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.
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
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!
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
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?
What is it that you want me to do?
Can you write me a small snippet of code that demonstrates your problem?
The eXpress train is coming - and it has more cars.
Re: DCSAY... GET .... VALID ... question
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.
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
Ok, thanks. I'm glad you found a solution.
The eXpress train is coming - and it has more cars.