[Solved] Global Chr() problem

[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.

[pjay]

Try the following in your FindExt() procedure to see if the exdot$ contents has been modified (debugger enabled):

Code: Select all

ShowMemoryViewer(@extdot$,2)

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.)

[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

[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.

[boddhi]

Hi,

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

[BarryG]

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.

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.

[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$)

[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.

[boddhi]

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...

[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?

[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...

[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.

[Fred]

did you tried the purifier with asm compiler ?

[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$)

[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