Re: [WIN]Win32Lib: v50 : trap click in SIMPLE combo?
- Posted by Derek Parnell <dparnell at BIGPOND.NET.AU> Dec 02, 2000
- 484 views
------ 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.