TITLE – Window Internals at runtime

“OK, what window are you in?”

“The Spanner Controller window.”

So here I’m shooting for the browser, w_spanner_controller? Nope, no w_spanner anything. W_controller_spanner? Nope, no w_controller anything.

“OK, what’s in the titlebar?” I ask, my frustration growing.

“Untitled, what does that mean?”

Have you ever worked on a system that had literally hundreds of windows with names that are not intuitive? I’ve seen names like w_a13_6.

There are times that at runtime we would love to get information about a window from the user. If only there were a way…

This solution requires a two prong approach. It requires that you have a base class window and a base class menu (see the NOTE at the bottom). Let’s start with the window.

W_base.ue_internals

You need to create a user event that you will call from the menu (that’s why we start with the window, so the menu will have something to call).

I called my event ue_internals but of course you can call it whatever you like, flying_coat_hangers leaps to mind.

Now add the following code. Note that I’ve left out the header comments that I always provide. I did that so that you don’t have to wade through all that.

Let’s take a look at this code. I’ve numbered it so we can talk about it.

Line 3 defines a ClassDefinition object for this object (the window that you are in). That gives us some very handy information.

Line 4 gives me a ClassDefinition for my immediate ancestor.

You might notice that I create a classDefinition for the ancestor but I didn’t do that for the lcd that was populated in line 3. How is that? The classDefinition for THIS window comes with the window. It’s already in memory and doesn’t have to be created. That’s not so for the ancestor, it’s not in memory.

So now we come to line 8 where I start using ls_display. That’s a local string and I’m going to use it to display my internal structure. In line 8 I use that ClassDefinition (here called lcd) and I get the library where this window is stored. I add a dot and then the title of the window, followed by the name (that’s the name like w_client_update) in parenthesis. That gives me everything I need to identify and find that window. This is the first line in the figure that you see in the article. Do you notice that I put a “~r~n~r~n”? That gives me two ‘carriage return/new lines’

Now I go into a loop from lines 13-14. I use these to populate an array of window names that are all the ancestors for this window.

In lines 15-18 I loop through that array (backwards) and add each name to ls_display with a “->” between them

Line 21 gives me the name of my menu.

In my example I have no debug messages defined so they won’t appear. If I wanted to have them appear I could add this code wherever I choose:

Starting in line 28 I loop through each of the datawindows showing the pbl.name then info for each. This ends in line 33.

Finally in line 36 I show ls_display.

We open the base level menu. Add a top level item. I call mine invisibles. Set the visible attribute to FALSE. Now it and all of the submenus will not be visible to the user.

Add a submenu item. I call mine ‘internals’.

Here is the script for internals:

The parentWindow is not likely to be a w_base as it is defined in the first line but that’s OK. We can define it as w_base as long as in this script we do not access anything that does not exist in a w_base.

The last thing is to give it a shortcut for ctrl-alt-d.

NOTE you don’t really need a base class menu but if you don’t then you need to add the invisible menu item to every menu that is used in a window wherein you want this functionality.

That’s all there is to it. Now when the user calls and says “I don’t know where I am or how I got there” you can just say, “hit ctrl-alt-D and send me a screen shot.”