“rlb” <robert.bottemiller@fmcti-dot-com.no-spam.invalid> wrote in message
news:dlg31f$cjn$2@inn.qnx.com…
Scenario (using Momentics 6.3 Pro w/SP2):
Using PhAB, Windows A, B, … are created along with internal links
ABM_A, ABM_B, … There are several tens of these (32 at latest
count) with a modest population of children widgets in each.
Do you mean 32 different modules, with possibly multiple instances of each,
or a smaller number of modules, with a total of 32 instances?.. (Unless
the total is way over 32, it probably doesn’t make a huge difference to the
general reasoning.)
If I understand you correctly, you want only one of them to be visible at
any given time, and your question is whether to keep the other windows
hidden behind it, or unrealized, or destroy them, correct?
In the base window of the PhAB app, a PtTree has a list item for each
window and a callback that would instantiate its window something
like this:
w_A1 = ApCreateModule(ABM_A, …)
where w_A1 is a widget pointer to the 1st instance of window module
A.
It sounds like each tree item knows which of the PhAB modules is “its”
module, but you can have multiple items associated with the same module –
that’s where A1, A2, etc. come from, right?
If the user can browse and click in the tree-structured list at
random, there is the potential for creating an unlimited number of
instances of any/all of the available windows. (Unless, by magic,
each new click destroys the current window.) So there appears to be
a need for controlling this situation and I can think of two
alternatives.
If I imagine the whole situation more or less correctly, I don’t think it
would be a good idea to let the app create more than one window instance
per tree item; if each item keeps track of its window instance, you
won’t have more instances than you have tree items, right? Can the number
of tree items grow indefinitely?
Strategy #1: Allow at most one instance of each window.
When the list item is clicked for window A, the callback should do
something like this:
if (w_A == NULL)
w_A = ApCreateModule(ABM_A, …);
else
PtRealizeWidget(w_A);
Didn’t you mean PtWindowToFront()? If yes, then this is exactly how
ApCreateModule() handles dialog modules. If no, then you’ll need code
somewhere to unrealize windows when you no longer want them visible.
Advantage: Window doesn’t have to be created again.
But if several different tree items share the same window instance, they’ll
have to fill the widgets with new contents, right?
Disadvantage: Potentially having 30-40 windows hanging around in
memory.
Well, how much memory do you have? I imagine an unrealized PtWindow costs
you around one K of memory; a PtButton probably half of that (unless it has
an image, or a lot of callbacks, or a very long string). Realizing the
window will probably take two or three K of pwm’s memory, plus Photon will
need a hundred bytes or so for each widget that has a region (such as a text
field, or any container that has a text field in it). (Disclaimer: these
are just ballpark guesses. Run a test if you want real numbers. Create 400
or 4000 windows to filter out random fluctuations.)
Strategy #2: Allow only one window at a time.
Here a global widget pointer records that last-created window and
always forces it destroyed before the new one is summoned. So each
tree item callback would do something like:
PtDestroy(w_last);
w_last = w_A = ApCreateModule(ABM_A, …);
If the windows overlap (like I imagine they do), it might be a better idea
to create the new window first, and then destroy the old one; otherwise,
whatever is behind will get an expose and possibly cause unnecessary flicker
by drawing its stuff just before the new window covers it again. Even if
you know that it belongs to the same process and therefore can’t draw before
getting covered, it’ll still get the expose and waste time running the code
that draws its widgets.
Advantage: Only one window created/realized at a time.
Disadvantege: You gotta create each window anew.
Unless you create them all at startup, the other scenario involves creating
a window the first time you click on an item, too – in other words, some
clicks may be faster when they reuse an existing window, but the worst-case
behaviour is the same. Are you more concerned about how long it takes you
to respond to a click in the worst case, or is the average time more
important?
Question: which is best under the circumstances of “several tens” of
not-very-complex windows.
Whatever makes your code simpler, unless you’re really tight on memory or
CPU cycles. 
OK, this looks like a typical time vs. memory space trade-off, but is
there some Photon behavior that would tend to favor #1 over #1 or
vice versa?
If I had to choose between #1 and #1, I think I’d pick #1. 
BTW Another thing to consider is that creating an instance of a PhAB module
involves reading resources fom the executable. If the file may be on a slow
filesystem, such as NFS or a CD, it might be worthwile to suck everything in
while the file is still open and the CD is still spinning, to avoid delays
when someone clicks on a tree item. (PhAB library attaches a callback to
the base window that closes the file when the window loses focus.) Also, if
there’s a chance that the executable may get updated while the application
is running, you probably don’t want the old process to try to read from the
new file.