Variable out of scope

[Cliff Nichols]

Is there some API that can tell if a Variable is out of scope? Or some way I can invalidate the variable so as not to cause a "crash" in a dll?

In my case (this is a bad example, but will give you the idea) lets say my variable is "HwndMain" and its value is the handle to my window. Now lets say I have a message box that pops up, waiting for a reply, but I close the window that "HwndMain" holds the value for, and then answer the msgbox. Now the variable still has the value, but the handle is invalid, so if I send something to it, I can cause a "crash"

I could use IsWindow(HwndMain) to verify, but I am thinking in more general terms of a function like "IsVariableValid(HwndMain)"

Is this possible? or do I just have to go back and bulletproof for silly things like closing a window that is about to be used?

(Bad example I know, but it is the only one I can think of to describe the problem)

[Fred Harris]

One of the major bad things about using global variables in Windows programming is that sometimes they hold valid values and sometimes they don't. And, since you have no way of determining which sequence of actions a user might take regarding the GUI, you may have a hard time knowing when a variable of global scope might contain a valid value and when it won't. It all depends on what the user just did, what procedures just executed, and so on. I think this is an architectural issue, and also an arguement against using globals. I know this is an oblique way of answering your question Cliff, but its all that immediately comes to mind.

[Cliff Nichols]

One of the major bad things about using global variables in Windows programming is that sometimes they hold valid values and sometimes they don't.

My thoughts exactly!!! (Now that I am understanding the whole problem of Globals, may or may not mean what you set them to, because another function may have changed it, or worse yet in the midst of changing it at the moment you ask for the value)

And discussing with my brother-n-law some basic problems (He is mostly Java developer), we determined that in the scope of my question, that I could either check every line I can think of, that the user did something I did not think of, or attempt to "Beef-Up" the error handling involved to ensure the user can not do what I did not think of.

Monumental problem depending on the code-base, but hey....thats why software crashes all the time....either the programmer was lazy, did not think of it, or the user did something they shouldn't (whether they knew it or not)

Since its up to me....and I am the not so lazy programmer, (I will admit I do NOT know all the details of a function, and I know 99% of my users have No CLUE what they are doing) it is on my shoulders to "Bullet-Proof" as much as "The point of Diminishing-Returns" allows for.

One key point I am looking at, is StreamInString to a RTF window, that all I can find, is it uses pointers to put new text to a Richedit window, but the docs say it uses the callback for the Richedit, but I find NOTHING showing me what the callback function contains?

Good part of what I get, I have been lectured enough on how a dll works vs how a exe works, to start tracking down why the exact same code works perfectly as exe, but compiled as dll crashes (or close to figuring it out). Bad Part is what I once thought was bullet-proof, I now see areas that were either flawed in thought, or some other mis-coding.

Anyways, if someone detailed tell me what StreamInString does and how it works, I would love it (I need to test but I think dwCookie is the window to post the text to? (although I always think of cookie as internet cookies? ))

Anyways, just tracking down odd things, and planning to avoid them in future re-writes.

[Michael Mattias]

>Is there some API that can tell if a Variable is out of scope?

"Variable scope" is a compile-time thing.

(That means "no")

[Cliff Nichols]

I was afraid MCM would confirm what I was thinking.

Variables out of scope, are out of scope in runtime....not compile time.

User doing something outside the scope of what you intended...well still out of scope

Probably the reason for the phrase "Scope-Creep"

Unfortunately compiled as Exe, everything I can think of passes, Debug, Array boundries, Window (or Dialog) exists, etc....
(Window (or Dialog) exists because it is my "Process", but if compiled as DLL then my code is mapped into its "Process") which is the only difference I can find.

That said, 2 thoughts I had and can not seem to phrase correctly on google nor in the forums to get a definitive answer is some way of determining (from my dll) if the "Process" is either closing or closed, and then adjust accordingly to prevent "Crashing" and either not use "bad Handles" or close running functions, so that things close properly?

I know the instance of my dll, but not who called it, or how to check if who called it is no longer valid? (and thats assuming the true "Great-Great-Great-Grandparent" is not a interpreted language running instead of a true compiled exe")
My only tests with true compiled vs interpreted, work much like VB6 not liking multi-threads, or not cleaning up correctly. Because If I make a true exe all is fine, but if looking at it as a developer using someone else's dll and crash everytime I make a change, makes me not want to use that dll)

Like I said..."Catch 22"...doggoned if you do, and your dog is gone if you dont

[Michael Mattias]

If you are having problems when your program ends, it's more than likely error 1: Programmer Error.

The DLL is loaded in your process space until LibMain gets DLL_PROCESS_DETACH. That is, however, a notification not an opportunity and once that message has been disposed of you cannot use any functions in that DLL.


Given your problem...

Now lets say I have a message box that pops up, waiting for a reply, but I close the window that "HwndMain" holds the value for...

... your problem is simply, "Don't allow the window to close until the message box has been dismissed." Easiest way is to eschew the intrinsic MSGBOX statement and use the WinAPI MessageBox function, specifying hWndMain as the parent window... MessageBox will automaticaly disable hWndMain until MessageBox has returned.

MCM

[Michael Mattias]

(DUH)

EnableWindow hWndMain, %FALSE
iret = MSGBOX (whatever)
Do stuff
EnableWindow hWndMain, %TRUE

[norbert doerre]

Cliff, hWnd is just a varialble like any other. So, the programmer is responsable for it's content. but tht's clear to all of us.
But You could perhaps generally observe variables for content depending from events, for instance with:

Function WaitEvents(hAccelerator As Long, hWndAccelerators As Long) As Long
	Local WinMsg As tagMSG
        '
        '
        '     
	Do While GetMessage(WinMsg, 0, 0, 0) <> 0
		If TranslateAccelerator(hWndAccelerators, hAccelerator, WinMsg) = 0 Then             
			TranslateMessage WinMsg             
			DispatchMessage WinMsg
                        '
                        '
                        '
		End If     
	Loop
        '
        '
        '
	WaitEvents = WinMsg.wParam 
End Function

I'm just fighting with getting the contents of the just activated table of a SysTabControl of another application urging me to use just this event driven content monitoring of variables.

[Cliff Nichols]

MCM gave me a few points to think on.

If you are having problems when your program ends, it's more than likely error 1: Programmer Error.

Yep...got that..."but I would NEVERRRRRrrrrr make a programming error"

The DLL is loaded in your process space until LibMain gets DLL_PROCESS_DETACH. That is, however, a notification not an opportunity and once that message has been disposed of you cannot use any functions in that DLL.

After all our conversations, I get how "Technically" my DLL is in my process space, for lack of a better term, its like dynamically adding *.Inc files to my *.Bas file (but at run-time and not at compile time) sort of thing

The part of notification and not an opportunity I TOTALLY missed until I was writing this reply, but it hit me, the function is more ("Hey, you are now part of the program", or "Hey, you are now alone") type of thing than it is "Hey you are ABOUT to be" part or not part

Given your problem...
... your problem is simply, "Don't allow the window to close until the message box has been dismissed." Easiest way is to eschew the intrinsic MSGBOX statement and use the WinAPI MessageBox function, specifying hWndMain as the parent window... MessageBox will automaticaly disable hWndMain until MessageBox has returned.

Given simply, add the %MB_TASKMODAL rather than the shortcut of no flags in a messagebox ( <---Guilty as charged cause I often take the shortcut when trying to check a problem I can not track down)

The other option I have to look at is

EnableWindow hWndMain, %FALSE
iret = MSGBOX (whatever)
Do stuff
EnableWindow hWndMain, %TRUE

which I believe when I try it, will give the same sort of results as %MB_TASKMODAL flag

Now that I have typed so long in a reply and the one thing I was going to ask, MCM may have already stated, but I did not get the concept at first was "Notification...NOT opportunity"....AKA if I can catch the <"quote unquote"> parent closing, and call the cleanup function and all errors go away...but if I rely on the "Notification" of LibMain then my cleanup may never happen, and hence my crash.

(or at least tests seem to follow what I think I am being told happens)