Re: [WIN]Win32Lib: v50 : trap click in SIMPLE combo?

new topic     » goto parent     » topic index » view thread      » older message » newer message

------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)

----- Original Message -----
From: "Dan B Moyer" <DANMOYER at PRODIGY.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, December 02, 2000 10:15 AM
Subject: Re: [WIN]Win32Lib: v50 : trap click in SIMPLE combo?


> Derek,
>
> That's ok; besides, it was a *good* example, just not quite what I needed!
> :)
>
> But I think your last suggestion only works with v 54.5??  See, I'm trying
> to get this to work with v50, 'cause it relates to my modification of
> Judith's IDE & that's not yet built to run under 54.5.  I'm beginning to
> think that maybe I *can't* do this under v50 (& even if I could, by making
> changes to v50, that wouldn't really help, 'cause I wouldn't want to have
to
> distribute the changed Win32Lib in order to get my mod to the IDE to
work).
>
> Wolfgang has sent me a list of Combo Box Notifications, not sure if they
> will help, but I'll give them a look.
>
> Maybe if I tell you exactly what I'm trying to do, that might help:
> In my mod of  Judith's IDE I have pairs of combo boxes, one above the
other
> in each pair; each of mine have a list of *categories* in the top box, and
a
> (variable) list of routines in the bottom of the pair; when a category is
> selected from the top of a pair, it causes the bottom combo to become
> populated with the appropriate list of routines for that category, opens
the
> bottom list, and either closes automatically or is closed by command (I
> forget which); this much works, you can see it in the latest version at
user
> contributions at RDS.
>
> What is supposed to happen next is that if the user clicks on the
> *categories* list while the lower *routines* list is down, it is
*supposed*
> to close the lower list so it doesn't show "under" the other list if the
> lower list is too long.  This also does work.
>
> The problem is that all of that works when the combo box is a *regular*
> combo box, with an *editable* control at the top, and if that is
> accidentally changed by a user, it crashes the IDE; so I thought to make
it
> *uneditable* to fix that "crash potential", but when I do that, I loose
the
> "close the bottom list when the top list opens" capability, because I was
> using "onGotFocus" to let me know when the user had clicked on the top
> combo, and when I use "SimpleCombo" it doesn't/can't get focus because it
> has a static text item, which can't get focus.
>
> If that's not clear in relation to my Mod, I'll try to send you a demo,
but
> I'm having trouble with my phone lines & can't be sure when I'll be able
to
> send/receive email.
>
> Dan
>
>
>
>
> ----- Original Message -----
> From: "Derek Parnell" <dparnell at BIGPOND.NET.AU>
> To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
> Sent: Friday, December 01, 2000 1:48 PM
> Subject: Re: [WIN]Win32Lib: v50 : trap click in SIMPLE combo?
>
>
> > Dan,
> > I don't know what I was thinking. My previous example was typed after
I'd
> > just flown back home from Sydney. Well its a beautiful morning now  here
> in
> > Melbourne and my mental cobwebs have disappeared (I guess).
> >
> > All you have to do is change win32lib.ew thus...
> >
> >   classAttr[SimpleCombo]=0
> >
> > becomes
> >
> >   classAttr[SimpleCombo]=w32Clickable
> >
> > This will now send onMouse events, and onClick when a selection from the
> > dropdown list is made.
> >
> > A similar change for Combobox, etc... should also work for those control
> > types too.
> >
> > ------
> > Derek Parnell
> > Melbourne, Australia
> > (Vote [1] The Cheshire Cat for Internet Mascot)
Dan,
I know exactly what you are trying to achieve. Simply put, you wish to
populate the contents of one list based on the selection in another list.

I needed the same function and that's when I discovered that win32lib v0.50
and earlier delibrately ignored mouse events (except right-down) from
controls that had a parent control. It did this to get out of trying to
handle "double" events happening for some controls that issued their own
mouse events. I've rewritten mousehandling in the current library to cater
for this type of thing. The only thing you can do for v0.50 is to use
onEvent (because that gets *all* events) and roll-your-own mousehandling for
the control. It would be similar to your wdemo.exw code except that you
filter out messages you don't want. Good luck.

-----
Derek.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu