Double tools stack and LookAndFeel

[Wilhelm Sanke]

As  I temporarily do not access the Metacard list on a regular basis 
(due to other urgent predelictions) I noticed that a post I sent two 
weeks ago did not reach the list because of a typo in the address. I 
will try to change my presents habits.

Meanwhile I want to thank Richard Gaskin for the new version of the MC IDE.

I hope the list members and especially Jacqueline - to who I refer - 
will excuse to receive my belated insights only now.

On Fri, 30 Dec 2005, "J. Landman Gay" <jacque at hyperactivesw.com> wrote:

1. "Double" mctools stack:

> >>>> 1. When the MC IDE is started, stack "mctools" appears to have been
> >>>> loaded twice.
>
> This is not limited to just the tools stack, it can happen to any stack.
> And it's been going on ever since I began using MC. I wrote to Scott
> Raney about it once, and now I can't find his answer, but basically it
> is just a cosmetic issue that means nothing. He said to ignore it.



The apparent problem is produced by some sort of an inaccuracy of the 
"stacks()" function: It lists only mainstacks, but for each opened 
*substack* of a given mainstack - for some reason that escapes me - the 
full path of the mainstack and the mainstack is listed again. With 
Message Box, Navigator, and Standalone Builder open the mctools stack is 
listed four times.
The "Windows Task-Manager" shows that only *one* instance of the 
Metacard Menu Bar is active.

Function "mainstacks()" accurately displays a list of all open 
mainstacks without repetitions.

For opened substacks we need "openstacks()" which displays mainstacks 
*and* substacks side by side without repetitions.

Seems to me the "stacks()" function needs some overhauling.


2. LookandFeel:

> >>>> Which means that the culprit must the new engine! I built a 
> standalone
> >>>> of the same stack in the Rev IDE with "Windows emulated" checked: 
> Same
> >>>> result, the produced standalone displays MacOS native features (like
> >>>> they appear on Windows).
>
> It is my understanding that look and feel is a session-specific property
> that is never built into the standalone or into a stack. (I can't
> explain why an older version of the engine would retain this property,
> though.) Look and feel must be set in a preOpenStack handler if you want
> to implement something different than the native OS appearance. It isn't
> meant to be a permanent property, so I don't think this is a bug.
>
> -- Jacqueline Landman Gay



Actually, all engine versions prior to 2.6 (from 2.5 and backwards) 
preserved the lookandfeel applied or automatically set in the IDE. As I 
see it, this is the way as it should be when I design the appearance of 
an application. Why should the engine (or for that matter the Standalone 
Builder) enforce a different appearance?
Of course you can set the lookandfeel in an (pre)openstack handler - 
this works - , but I would like "to get what I see" when I work in the 
IDE without the necessity to script what I see all the time when 
developing.

Maybe we could improve the MC Standalone Builder as a workaround (until 
maybe the engine has reverted to older standards in this case, which 
however seems rather improbable to me) with a function that looks for 
the presently applied lookandfeel and sets this as a property of a 
standalone.
Another related issue: We lack an "Appearance Manager" option in the 
Preferences substack.

Regards,

Wilhelm Sanke