Menu and Null Object Refer. Message

[Gerry]

Recently a coworker asked me why the following line of code will now and
then cause a "null object referenced" message in their window event.

m_menu.m_file.m_delete.visible = FALSE

I did not offer a reason but suggested the code would work better if it was
changed to the following:

m_menu l_menu
l_menu = this.menuid

l_menu.m_file.m_delete.visible = FALSE

I have used this method for years and have found it always works, but
cannot offer a technical reason. Can anyone elaborate on which is the
preferred method and why.

Thanks.

[Michael Walker]

Gerry
I believe this is caused by PowerBuilder's use of the memory. Without going to
deep into Class, Instance, and reference variable memory pools, I'll try to
explain. When you open a window using the following...

Open(w_mywindow)

PowerBuilder creates a global variable named w_mywindow that points to this
window in memory. This is how you can reference this window with code...

w_mywindow.visible = false

It basically does the same thing with menus. If you open a window that has a
menu named m_sheet associated with it, it creates a global variable named
m_sheet which points to the menu. When you open a second window with that same
menu associated with it, PowerBuilder has a little quandary. The obvious
problem is that PowerBuilder can't have two global variables with the same
name. So what happens is that the m_sheet global variable now points only to
the menu on the second window. At this point, any reference in script to
m_sheet, will only affect the menu on the second window, even if the code is
coming from the first window. When the second window closes, the m_sheet
global variable is destroyed. Once the variable is destroyed any reference to
m_sheet will give you a null object reference.

So basically, if you open two windows with the same menu, then close the second
window, you risk having null object errors. This scenario isn't that common,
which why you only see those errors from time to time.

Using your method will always work because the menuid property is specific to a
window. So it always points to the instance of the menu for a it's window,
regardless of how many instances of the same menu exist.

I hope I didn't confuse you further.

Good Luck

Michael Walker
Cascadia Software

[Paul Cotter]

Hi Michael

An excellent explanation. The only bit I query is the time of creation of a
global variable. An object does not have to be created to be referenceable.
So in line 1 of your application open script you can write

if isValid (w_any_window_from_any_pbl ) then
MessageBox('sanity','problem')
end if

To all intents and purposes all visual objects are global variables even
before you have created or referenced them. Questioning whether they existed
before you referenced them is like 'does a falling tree make any sound if
there is no-one to hear it'.

I keep a 'concept' in my mind that this global object is a pointer and every
time you create something the pointer flips across to the most recent
creation.

This is probably not very scientific description of what happens in PB
internals, but thinking that way has helped me find a few interesting bugs.

And to Gerry - yep, you've always done it right, as Michael described so
well. My personal advice (and some will disagree with this) is to NEVER
reference any object by name, even a response window. Sooner or later it
will come back to haunt you. And if for no other reason it is quicker to
compile

open (lw_Response, 'w_select_option')

than

open (w_select_option)

It made a huge difference on pre-pfc menus. The only advantage for option 2
is that it will not compile if you mis-spell it or accidentally delete the
window.

"Michael Walker" <mwa...@cascadiasoftware.com> wrote in message
news:3C4F4434...@cascadiasoftware.com...