Global variable value is changed by HReadSeekFirst in different window.

The two different trace windows will show a different result depending on which Organizer appointment you have selected. For example, first Frame_Deb.GnDebNr was 11 then when searching on the file with HReadSeekFirst it will change to the F_agenda.Patient_nr value. The phenomenon occurs for every HReadSeekFirst method call in this window. I can of course cancel these effects by saving the data to a variable prior to the HReadSeekFirst call.



List of actions I performed to address the problem:
• Assert on expression Frame_Deb.GnDebNr > Will assert on the HReadSeekFirst line
• Breakpoints on all search results of “gndebnr “ in both code and GUI > Not breaking in between the lines
• When using “Detailed step by step” from the debugger on the first Trace line, with Strict mode enabled. It shows the HReadSeekFirst method changing the value of the said global variable.
• Checked all the parallel tasks, temporary disabled them, had no impact.
• Tried using the Performance Analyzer to detect code that I could have missed.
• Recompile and synchronized the Project, no success
• Repaired the Project and synchronized its Analysis
Did anyone had a similar experience? Or does anyone know how to find the issue?
Thanks in advance,
Koen

Hi Koen

Is Frame_Deb.GnDebNr a variable or a control?
If it is a control linked to a field of the file F_agenda, the behaviour is normal (unless you're having different HF contexts).
Maybe if it is a real variable that has a <mapping xxx> attribute attached in its declaration it may work like that too.

Also, in your Window settings, do you have 'Independent HF Context' flagged? If not, it will use the global Hyperfile context for the application causing this behaviour too.

PS: I never have controls bound to database fields since it's hard to separate concerns and do multi platform dev.

Cheers

Peter H.



Edited 2 time(s). Last edit at 06/22/2021 06:24PM by PeHoBe.

Hi Peter,

Thank you for your extensive reply!!

Both windows are indeed on 'Independent HF Context' and Frame_Deb.GnDebNr is a variable without any link to an actual data file.
It is called within the 'global declarations' of the window by 'Frame_Deb.GnDebNr is int'
The strange thing, no code is called to alter it whatsoever! Otherwise, a breakpoint would have triggered, but this is not the case...

One 'main' window will call the Open() and OpenSister() functions for both. From thereupon, they should be completely separated.
Is there any other way to determine the issue?

Kind Regards,
Koen

Koen,

I have had issue with a variable changing years ago. Don't remember all of it but the fix for me was to declare it with "Local" keyword and that fixed it. Had something to do with passing the value it is by address.

so try 'Local Frame_Deb.GnDebNr is int'

DW

Dear DW,

Thank you for your fast reply!!
Sorry for my late response.

Applied your suggestion of using the LOCAL keyword, this did the trick!!!
Thank you very much, I thought this was only required for recursive functions.

Kind Regards,
Koen

This kind of thing happened to me a few years back, and I wouldn't have found the problem without Fabrice's help. This is what was happening in my case:

I used the 'changing' variable in a procedure call, as a parameter
In the procedure, I changed the value of the corresponding parameter
Because the parameters are passed by default BY ADDRESS, this would modify at the same time the value of the original variable in the original code...

Example to be clear:

asMyChangingVar is ansi string = "test" //in the original case, it was a file item, but that is the same problem
...
asResult=MyProcedureDoingSomething(asMyChangingVar) //called anywhere, even in a timer
...
asMyChangingVar suddenly = "other value"

in the procedure:

procedure MyProcedureDoingSomething(aspar_Parameter is ansi string)
...
aspar_Parameter = "other value" ..... THAT's IT


so, in order to solve that, you can now declare your procedure's parameters as being passed by value, or you can NEVER set any value in the aspar_Something variables (which is why I now name them like that, following Fabrice's advice)