standalones again -- problems

[Peter Brigham]

OK, an update on my efforts to port a simple standalone to Mac and  
Windows. I don't yet know what to make of the reports of the Mac  
version failing to run at all, as there is not enough feedback to  
know how to deconstruct the problem, and it runs fine on our two  
machines. With the Windows version, here is what I have found so far,  
downloading the app direct from the website on several PCs I have  
intermittent access to and testing it briefly. (None were running  
Vista.) BTW, the new version of the app adds the feature of allowing  
the user to group recipes by category and navigate within a category,  
as suggested in one response.

1. The Win build will not open in a resizable window. I have set the  
resizable of the stack to true both initially (as compiled by the  
standalone builder) and in the preopenstack handler as a backup, but  
no go. The Mac version does this fine. I have checked off "geometry"  
as one of the inclusions in the standalone prefs, didn't know if this  
was necessary but I played it safe. Bottom line: on the Mac,  
resizable, on Win, not.

2. Because of problem 1, I inserted in the preopenstack handler some  
resizing commands to avoid the problem of the stack window being  
larger than the working screen rect, which it turned out to be on one  
smaller PC screen:

   put the uRect of this stack into rct
   -- uRect = the rect of the card window, stored as a
   -- custom property with every movestack and resizestack message
   put item 3 of rct - item 1 of rct into wndW
   put item 4 of rct - item 2 of rct into wndH
   put the working screenrect into scrRct
   put item 3 of scrRct - item 1 of scrRct into scrW
   put item 4 of scrRct - item 2 of scrRct into scrH
   set the maxwidth of this stack to scrW
   set the maxheight of this stack to scrH
   if wndW > scrW or wndH > scrH then
     set the rect of this stack to scrRct
     set the uRect of this stack to scrRct
   else
     set the rect of this stack to rct
   end if
   set the resizable of this stack to true

The docs say the "working screenrect" is the effective screen real  
estate minus the mac menubar & dock and the Win minimization bar at  
the bottom, so I thought this would at least manage things while I  
figured out the "resizable" problem. But with these commands in  
place, the Win application opens with its topleft at about 150,150  
and the bottom and right edges of the window off the screen. This  
remains true even if I move the stack so it's fully onscreen, save  
it, quit, and open it again. The uRect should have been noted and  
saved with the movestack handler so it will open at the corrected  
location, but the window is back at 150,150 (topleft) again. The Mac  
version works properly, ie, it opens at the location it was last left  
at (actually with the rect it had when last closed). I can't figure  
out this Windows behavior at all.

3. I have an option list (a menu button of style "option") as a  
navigation tool. On the Mac build, clicking on it drops down the list  
of recipes; selecting a recipe from the list sends you to that card,  
and typing a letter moves the hilited line to the first recipe  
starting with that letter. Also, hitting <return> is equivalent to  
clicking the currently-hilited line, again requiring no scripting,  
and the scrollwheel (or two-finger dragging on the Mac trackpad)  
scrolls the list as necessary, again no scripting needed, and up and  
down arrowkeys move the hilited line (no scripting). AFAIK this is  
expected behavior and is built into the way the option-menu works.  
The Win option-menu is not fully functional: the list appears OK, and  
you can scroll it by dragging the scrollbar (not present on the Mac,  
BTW), and clicking on a line takes you to the correct card, but the  
scrollwheel does nothing (though it works with scrolling fields), and  
<return> does nothing, and typing a letter on the keyboard does  
nothing, and arrowkeys do nothing. Also, the current recipe is not  
hilited when the menu drops down (it is on the Mac) although this is  
scripted by setting the menuhistory on mousedown.

So, I put this in the script of the option button, to try allowing up  
and down arrowkeys to move the hilited line:

on arrowkey which
   put the menuhistory of me into L
   if which = "up" then
     if L <> 1 then
       subtract 1 from L
     end if
   else if which = "down" then
     if L < (the number of lines of me) then
        add 1 to L
     end if
   end if
   set the menuhistory of me to L
end arrowkey

This also has no effect on the Win version, though it works fine in  
the Mac build. The Win build acts as if it is ignoring a bunch of  
messages here. Is the button somehow losing the focus?

There are too many things going on here that I don't get. (There is  
another problem also with a popup menu, but this is too long already  
so I'll leave off for now.)

Any advice appreciated. I realize that some of this must be obvious  
to those more experienced than I, but I'm trying to learn....

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig/

"The Japanese have perfected good manners and made them  
indistinguishable from rudeness."
               -- Paul Theroux