Page 1 of 2
[Solved] Global Chr() problem
Posted: Fri Mar 22, 2024 8:05 am
by BarryG
[Edit]
Solved. I think a thread was using the variable before Global for it was set. Sorry for wasting everyone's time.
Check out this simple snippet:
Code: Select all
Global extdot$=Chr($2024)
Procedure test()
Debug extdot$
EndProcedure
test()
Works great. But it in my big source, the Debug output is an empty string, despite the variable being Global before the Procedure.
Here's a screenshot from my source showing the problem:
I noticed if I change it to a constant instead of a global, then it works:
Seems something is up with Global and Chr(), so this is a
heads-up to Fred that maybe something needs checking in the compiler?
And before anyone asks: YES, I have checked that the variable name "extdot$" does NOT exist in my source anywhere else.

Re: Global Chr() problem
Posted: Fri Mar 22, 2024 8:23 am
by pjay
Try the following in your FindExt() procedure to see if the exdot$ contents has been modified (debugger enabled):
If it has, try running your program with the ASM compiler, debugger and purifier enabled to highlight if it has been corrupted by a stray memory operation (Poke(), copymemory(), *pointers etc.)
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 8:31 am
by infratec
Your small example on top of your first post works here without problems and showing a dot in the debug window.
PB 6.10 b8 ASM x32 on Win10 x64
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 8:38 am
by BarryG
@pjay: The ShowMemoryViewer() command resulted in this:
Code: Select all
The specified memory location is not valid for reading.
Hmm. I also noticed it fails with simple Chr() too, like Chr(35) for "#", so it's not a Unicode issue.
@Infratec, yes, that's why I said it's all good in that snippet. The screenshot shows the runtime failure in the real source.
I just tried compiling with the C backend for the hell of it, and the exe just starts and quits with no error. Like, it shows in Task Manager for one second and then disappears from there. Back to the good old trusty ASM compiler again.
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:02 am
by boddhi
Hi,
BarryG wrote:
And before anyone asks: YES, I have checked that the variable name "extdot$" does NOT exist in my source anywhere else.
Ok, noticed but silly question (but you never know) : "does NOT exist" means NOT DECLARED AGAIN or NOT REASSIGNED (or both

)? In first case, are you sure that the value of the global variable doesn't change between the time it's declared and the time it's used in the procedure? What is its value when you enter the procedure? Is it still a dot? You didn't clearly specify that

Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:19 am
by BarryG
boddhi wrote:In first case, are you sure that the value of the global variable doesn't change between the time it's declared and the time it's used in the procedure?
It doesn't change. Currently, the global variable "extdot$" is only declared once, literally just before two procedures that call it. There is
never anything like "extdot$=" or "extdot$+" again in the source. Those two procedures are currently the only times it's used (more will come later). It's a new variable that I only added today, so that's why it doesn't exist elsewhere. I even did a search in all files to make sure, and then I even renamed it to something random as well to make sure.
boddhi wrote:What is its value when you enter the procedure? Is it still a dot? You didn't clearly specify that

I
did clearly specify it: look at what my screenshot shows. The MessageRequester is showing it's empty when the procedure is entered.

And also when I did what pjay said with "ShowMemoryViewer", the variable was empty. I always clearly show my work when questioning something, which is why I took the time to make such detailed screenshots.
In fact, if I remove the other procedure (not shown in the screenshot), then all instances of "extdot$" are literally what the screenshot above shows. That is: one global declaration, and one reference to it in the procedure under that declaration. Can't get any more simple than that.
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:29 am
by mk-soft
Code snipped works here
Code: Select all
Global extdot$=Chr($2024)
Procedure foo(file$, ext$)
MessageRequester("Test", extdot$)
EndProcedure
f$ = "file"
e$ = "txt"
foo(f$,e$)
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:35 am
by BarryG
Yes, I know it does. I said that in the first post ("All good, right?"). "Right" was rhetorical. I'll edit the post to avoid confusion, since two of you have now replied confirming that it works. That's not what I was asking.

Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:36 am
by boddhi
BarryGI [b wrote:did[/b] clearly specify it: look at what my screenshot shows. The MessageRequester is showing it's empty when the procedure is entered.

And also when I did what pjay said with "ShowMemoryViewer", the variable was empty. I always clearly show my work when questioning something, which is why I took the time to make such detailed screenshots.
I prevent it was a silly question!
Your screenshot just show that MessageRequester doesn't display a dot but not the real extdot$ value, hence my question...
We could think that the issue may also come from MessageRequester...
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 10:44 am
by BarryG
It shows that "extdot$" is empty, despite me never clearing it or touching it after creation. No string operations are done on it at all after Global.
I notice that if I move the Global declaration back up in my source before any CreateThread() commands, it works! So it's maybe a compile-time issue?
Re: [Solved] Global Chr() problem
Posted: Fri Mar 22, 2024 11:39 am
by pjay
The error that ShowMemoryViewer() presented indicates that the pointer to the variable had been corrupted, not that the string has been cleared.
In my opinion you've not solved this, you've masked it - whatever caused that corruption is now likely to be hitting other areas of your program that isn't (currently) presenting itself.
Personally I would invest the time to dig deeper for the root cause, as I have no doubt this will come back to haunt you later on, when your project is larger and more complex than it is today.
The fact that you had a known variable being corrupted was a *good* foundation for debugging...
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 1:00 pm
by BarryG
Okay, I've "un-solved" the topic for any other suggestions. I'm thinking now maybe a thread was trying to use it before it was declared.
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 2:34 pm
by Fred
did you tried the purifier with asm compiler ?
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 3:28 pm
by Michael Vogel
Tried different compiler versions and fonts, didn't see a problem here...
...maybe some additional clues in the message requester will show something?!
Code: Select all
Global extdot$=Chr($2024)
; And what about using other characters - Chr(8226) - will they be all invinsible?
Procedure foo(file$, ext$)
MessageRequester(extdot$,"'"+extdot$+"'"+#CRLF$+Str(Asc(extdot$)))
EndProcedure
f$ = "file"
e$ = "txt"
foo(f$,e$)
Re: Global Chr() problem
Posted: Fri Mar 22, 2024 9:11 pm
by TassyJim
Looking at the image of your source, the 'folding line' beside the line numbers suggest that the Global has been declared within a conditional statement of some sort.
Is that relevant?
Jim