mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (07/24/89)
Can someone help me out here? I have been working with the List Manager, and
have run into an interesting problem:
Sometimes, I will click on one item in the list, and it will become hilited.
Now, I click on the second item in the list, and it too becomes hilited.
But I have the selFlags set to -128 (lOnlyOne). That didn't help, so I
stopped passing theEvent.modifiers to LClick; I passed 0 instead (since my
list could never have more than one item selected in theory).
But it doesn't do this all the time. Has anyone run across anything like this
before?
Also, when I have this list in a modeless dialog, the dialog will take care
of update events with DialogSelect. But it won't update the list. Right now,
I am checking theEvent.what after calling DialogSelect, and if it is an
updateEvt, I call LUpdate with the proper list. Is this the best way to go
about it?
Thanks for any help,
-Michael
--
Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas
Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu
Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)jpd00964@uxa.cso.uiuc.edu (07/24/89)
> when I have this list in a modeless dialog
I also had horrid problems putting a list in a modeless dialog box. Most
of my problems were alleviated when I did as much as possible outside of
the filter proc. There is some incompatability, and I do not know where.
Michael Rutman
Softmedari@eleazar.dartmouth.edu (Ari Halberstadt) (07/25/89)
In article <227700017@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > >> when I have this list in a modeless dialog > >I also had horrid problems putting a list in a modeless dialog box. Most >of my problems were alleviated when I did as much as possible outside of >the filter proc. There is some incompatability, and I do not know where. I remember coming across this article where someone had trouble with lists in modeless dialogs. I've implemented such a thing and have no trouble at all. Unfortunately I can't find the article. Could the person who originally posted it contact me, and I will attempt to help (contact via direct email). -- Ari Halberstadt '91, "Long live succinct signatures" E-mail: ari@eleazar.dartmouth.edu Telephone: (603)640-5687 Mailing address: HB1128, Dartmouth College, Hanover NH 03755
tim@hoptoad.uucp (Tim Maroney) (07/25/89)
In article <227700017@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: >I also had horrid problems putting a list in a modeless dialog box. Most >of my problems were alleviated when I did as much as possible outside of >the filter proc. There is some incompatability, and I do not know where. I can understand having some problems with this -- the various code communications issues are a bit weird -- but there's really no incompatibility. Really, the only problems are (1) ModalDialog doesn't return an event record, so you don't get the click location and mouse modifier keys, and have to save them in a filter proc or figure them out after ModalDialog and (2) the list rectangle has to be inset fifteen pixels to compensate for any scroll bars. As long as you install a userItem procedure with the proper call to LUpdate, and make sure the scroll bar lies inside the userItem as described in (2), the whole thing works quite well. I don't know of any "incompatibilities". Difficulties, yes. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Genuinely skillful use of obscenities is uniformly absent on the Internet." -- Karl Kleinpaste on gnu.gcc
zben@umd5.umd.edu (Ben Cranston) (07/26/89)
In article <227700017@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > I also had horrid problems putting a list in a modeless dialog box. Most > of my problems were alleviated when I did as much as possible outside of > the filter proc. There is some incompatability, and I do not know where. In article <8115@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > ... the only problems are (1) ModalDialog doesn't return an event record... > ... (2) the list rectangle has to be inset fifteen pixels for scroll bars. > As long as you install a userItem procedure with the proper call to LUpdate, > and make sure the scroll bar lies inside the userItem as described in (2), > the whole thing works quite well. Tim, the user was talking about MODELESS dialogs and you are talking about MODAL ones. Nevertheless, I basically agree that it pretty much works. One area I have had trouble with is activate/deactivate, which only happens in the MODELESS case (you cannot put a MODAL dialog into background or indeed do ANYTHING until you satisfy it). The dialog manager KNOWS about TextEdit so it can deactivate and activate any included TextEdit items in response to the corresponding event. It does NOT know about the List manager in this way, so I found I had to manually check for these two events and manually call LActivate (before the IsDialogEvent/DialogSelect stuff as I recall). Other than that, I have had no trouble with lists in modeless dialogs... -- Sig DS.L ('ZBen') ; Ben Cranston <zben@umd2.UMD.EDU> * Computer Science Center Network Infrastructures Group * University of Maryland at College Park
tim@hoptoad.uucp (Tim Maroney) (07/27/89)
In article <227700017@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > I also had horrid problems putting a list in a modeless dialog box. Most > of my problems were alleviated when I did as much as possible outside of > the filter proc. There is some incompatability, and I do not know where. In article <8115@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > ... the only problems are (1) ModalDialog doesn't return an event record... > ... (2) the list rectangle has to be inset fifteen pixels for scroll bars. > As long as you install a userItem procedure with the proper call to LUpdate, > and make sure the scroll bar lies inside the userItem as described in (2), > the whole thing works quite well. In article <5129@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: >Tim, the user was talking about MODELESS dialogs and you are talking about >MODAL ones. Oops, sorry. I just couldn't imagine that anyone was really having problems with lists in modeless dialogs. They're incredibly easy. >Nevertheless, I basically agree that it pretty much works. One >area I have had trouble with is activate/deactivate, which only happens in >the MODELESS case (you cannot put a MODAL dialog into background or indeed do >ANYTHING until you satisfy it). The dialog manager KNOWS about TextEdit so >it can deactivate and activate any included TextEdit items in response to the >corresponding event. It does NOT know about the List manager in this way, >so I found I had to manually check for these two events and manually call >LActivate (before the IsDialogEvent/DialogSelect stuff as I recall). You ought to do it after IsDialogEvent and before DialogSelect. On the other hand, you don't really *have* to do it at all. If you don't, your scroll bar(s) will still show and that's the extent of the problem. Most users won't even notice. >Other than that, I have had no trouble with lists in modeless dialogs... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "What's the ugliest part of your body? Some say your nose, some say your toes, But I think it's your mind." -- Frank Zappa
zben@umd5.umd.edu (Ben Cranston) (07/28/89)
In article <5129@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: > The dialog manager KNOWS about TextEdit so it can deactivate and activate > any included TextEdit items in response to the corresponding event. > It does NOT know about the List manager in this way, so I had to explicitly > check for this event type and call LActivate (before the > IsDialogEvent/DialogSelect stuff as I recall). In article <8138@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > You ought to do it after IsDialogEvent and before DialogSelect. On the > other hand, you don't really *have* to do it at all. If you don't, > your scroll bar(s) will still show and that's the extent of the > problem. Most users won't even notice. I checked my source code and in fact I did do it after IsDialogEvent and before DialogSelect. It also checks for keyDown events, since it is doing the SFGetFile-type key-to-list-position stuff. For both these cases DialogSelect will return false but there is something else we want to do, hence the special case code. Yes, I realize it is pretty innocuous and nobody will notice, but I will notice! Like Hebrew National* hotdogs I have to answer to a higher authority. My code will never leave ghost select bars in inactive TextEdit items, and it will by <whatever you believe in> activate and deactivate its windows properly. I guess you can't fault Apple for falling down on this one. In order to do it right they would have to: 1. Extend item codes to include a "list" item, so the dialog routines could recognize lists in item lists. 2. Get everybody to make their lists as "list" items rather than "user" items patched after dialog load time. 3. Modify the dialog routines, which now search for textedit items to be activated and deactivated, to also activate and deactivate "list" items. I guess it was just easier to push the work off onto ALL the application writers... * This is probably a trademark of some huge food conglomerate. -- Sig DS.L ('ZBen') ; Ben Cranston <zben@umd2.UMD.EDU> * Computer Science Center Network Infrastructures Group * University of Maryland at College Park
tim@hoptoad.uucp (Tim Maroney) (07/29/89)
In article <5134@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: >Yes, I realize it is pretty innocuous and nobody will notice, but I will notice! >Like Hebrew National* hotdogs I have to answer to a higher authority. My code >will never leave ghost select bars in inactive TextEdit items, and it will by ><whatever you believe in> activate and deactivate its windows properly. Yeah, I'm not saying it's a good idea to omit LActivate calls, I'm just saying it's not all that serious if you do. Concern was expressed about crashing-type problems when using lists in dialogs, and I was just pointing out that this isn't a problem of that magnitude. >I guess you can't fault Apple for falling down on this one. In order to do it >right they would have to: > >1. Extend item codes to include a "list" item, so the dialog routines could > recognize lists in item lists. >2. Get everybody to make their lists as "list" items rather than "user" items > patched after dialog load time. >3. Modify the dialog routines, which now search for textedit items to be > activated and deactivated, to also activate and deactivate "list" items. > >I guess it was just easier to push the work off onto ALL the application >writers... Pretty much correct (though with respect to scroll bars, there's a better solution which involves using the window control list). Still, wouldn't it have been nice if Apple had added list items to dialogs? It would save us all some coding. Looking at the item list data structure, I can see that it would have been extremely easy to add a new type. Probably, though, they forgot to include the hooks in the ROM which would allow new item types to be added without putting in a whole RAM-based Dialog Manager. Oh well. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Those who restrain desire, do so because theirs is weak enough to be restrained..." - Blake, "The Marriage of Heaven and Hell"
jules@kauri.vu (Julian Anderson) (05/23/91)
I am using Lightspeed C (4.0) and am having a bit of trouble with the list manager. For some reason, as soon as a cell in the list is selected, the scroll-bars refuse to behave themselves, ie clicking in the down arrow works, but if you hold the mouse down, it refuses to scroll more than one. Also, the page up/down areas do not work at all. I am using just a standard list-box, ie no user-defined hook. Can anyone suggest to me what the problem is? Or have some C (Lightspeed, MPW, anything) that uses listboxes that I could have a nosey through? Thanks in advance, jules -- jules@kauri.vuw.ac.nz | `Anyone who cannot cope with mathematics is not fully jules@rata.vuw.ac.nz | human. At best he is a tolerable subhuman who as J.Anderson@72.Tasman. | learned to wear shoes, bathe, and not make messes in st.Wellington.NZ | the house.' - Lazarus Long.