Re: Clicks go where? (was Re: [MacPerl-Toolbox] Popup menus in dialogs?)

[Alan Fry <ajf@afco.demon.co.uk>]

>  >Alex Harper harper@misanthrope.net wrote:
>
>Spoke too soon, *sigh*
>
>I've rewritten my project without using Mac::Dialogs. Now its just a window
>with embedded controls (and I handle highlighting the default button, etc.)
>With the popup menu example Alan kindly supplied I've got a working window
>(buttons and all) so long as the window contains only controls (popups,
>buttons and checkboxes). I have a single 'hit' hook to toggle the
>checkboxes, and a 'hit' routine for OK and Cancel. I leave all the other
>control hooks alone (they seem to work fine with the default behavior).
>
>I added a list to the window recently, and it too works so long as I don't
>give it a hook for 'click'. Since the default behavior is fine for the list,
>that's OK by me, although I was surprised that setting the hook seemed to
>result in the list 'click' hook being called for any click in the window
>that was not within another control (i.e. all clicks on blank window content
>went to the list 'click' hook.
>
>Now I've added back the text fields I had in the original dialog version
>(using $win->new_textedit) and suddenly I'm broken. Here's the behavior:
>
>- If I do not override any hooks for the textedit object then text entry,
>tabbing between fields, etc. all work OK. However, all controls start having
>odd behavior. For example, when clicking buttons the button does not
>highlight, but on mouseup the action for the button occurs. When clicking a
>popup the menu does not popup immediately. Instead the menu pops up after
>the mouseup and selects the menu item that would be positioned under the
>location of the mouseup.
>
>- If I override the click hook on the textedit items then I see why the
>above happens. That hook gets called first for _every_ click in the window,
>regardless of location. With my hook all controls stop working (never see
>any clicks).
>
>I'm hoping I didn't read things closely enough, because that seems like its
>wrong. Surely the TextEdit should only gets its own clicks?
>
>For what its worth, I have a couple of window level hooks. A cursor hook
>which does mouseover help text, a key hook to handle default buttons (Esc,
>Return, etc.), and an idle hook which watches for changes and populates the
>list on the basis of other selections in the dialog. I understand that the
>'key' hook will eventually need to pass keys to the textedit fields (since
>it with it active the textedit fields won't take keystrokes). However, I
>disabled all these hooks and get the same behavior.

I think you may be right to use MacWindows rather than MacDialogs. A 
few weeks ago Kevin Reid and others pointed out that MacDialogs 
suffers from a memory leak. Also non-modal MacDialogs cause machine 
crashes using MenuBar 'Cut', 'Copy' and 'Paste'.

You might find MacTE.pm helpful in this context. It provides TextEdit 
single-line text-edit fields (Dialog fashion) registered as panes in 
a standard MacWindow. I think it deals properly with clicks in the 
window but outside the TE fields. MacTE can be found at 
http:/www.afco.demon.co.uk/ with documentation and example script.

You can add controls with Controls.pm and in particular PopupMenus 
work OK alongside MacTE. However I haven't tried a window with a List 
as well but see no reason to suppose it would cause any problems.

HTH,

Alan Fry

==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org