vrm@blackwater.cerc.wvu.wvnet.edu (Vasile R. Montan) (05/19/91)
There is a Tech Note called "Don't abuse the managers." This note gives some warnings about improper use of the managers. For example, it says that the List Manager should only be used for fairly small lists, because the list manager is not designed to handle big jobs, and trying to coerce it to do so will result in annoying delays for the user. While the rationale for most of the warnings in this tech note are clear to me, I don't understand the warning against using the dialog manager for anything but dialogs with simple buttons, static text, and editable text. The note says that if I am doing anything unusual, such as including a dial control, etc., I should set up my own window and do all of the dirty work of tracking the controls, etc., myself. Well, I've got several reasons why I don't want to do this: --If I'm drawing the controls myself into my own window, I will have to hard code their locations, while with a dialog I can drag the controls in the DITL around using ResEdit. I suppose it would be possible to create a DITL using ResEdit, then have my program read it in and interpret it just as the Dialog Manager does, but this would take a fair amount of coding which already exists in the Dialog Manager. --When I'm creating a new dialog, I never create it from scratch. Instead, I take the code of one of my existing dialogs and edit it to meet the needs of the new dialog. Since all dialogs work in much the same way, this is a speedy process. If I'm writing a long program, it seems like a waste of time to teach my buttons to hilite. --If there is something wrong with doing unusual things with dialogs, then why were userItems and filter functions created to start with? With the List Manager example above, there is a clear reason (speed) for not abusing the manager; if I 'abuse' the dialog manager, my code may be a bit kludgey, but how will the user ever know the difference? Am I way out of line? Comments? --Kurisuto un020070@vaxa.wvnet.edu
osborn@ux1.lbl.gov (James R Osborn) (05/19/91)
In article <1777@babcock.cerc.wvu.wvnet.edu> un020070@vaxa.wvnet.edu writes: > >There is a Tech Note called "Don't abuse the managers." This note >gives some warnings about improper use of the managers. For example, >it says that the List Manager should only be used for fairly >small lists, because the list manager is not designed to handle >big jobs, and trying to coerce it to do so will result in >annoying delays for the user. > >While the rationale for most of the warnings in this tech note >are clear to me, I don't understand the warning against using >the dialog manager for anything but dialogs with simple buttons, >static text, and editable text. The note says that if I am doing >anything unusual, such as including a dial control, etc., I should >set up my own window and do all of the dirty work of tracking the >controls, etc., myself. > > [stuff deleted] > >--If there is something wrong with doing unusual things with dialogs, >then why were userItems and filter functions created to start with? >With the List Manager example above, there is a clear reason (speed) >for not abusing the manager; if I 'abuse' the dialog manager, my >code may be a bit kludgey, but how will the user ever know the >difference? > >Am I way out of line? Comments? > >--Kurisuto >un020070@vaxa.wvnet.edu I do indeed concur whole-heartedly with all of your sentiments... ^ ^ 0 0 > \___/ -- James |-----------------------------------------------------------------------| | James R. Osborn | It just goes to show you it's always | | Lawrence Berkeley Laboratory | something. Either it's incorrect tech | | osborn@ux1.lbl.gov | notes or your mac is smoking. It's | | (415) 548-8464 | always something... | |-----------------------------------------------------------------------|
gurgle@well.sf.ca.us (Pete Gontier) (05/21/91)
osborn@ux1.lbl.gov (James R Osborn) writes: >In article <1777@babcock.cerc.wvu.wvnet.edu> un020070@vaxa.wvnet.edu writes: >>--If there is something wrong with doing unusual things with dialogs, >>then why were userItems and filter functions created to start with? Hee hee. Because Microsoft wanted that stuff. 'nuff said. >I do indeed concur whole-heartedly with all of your sentiments... Me too. What's most important to remember about that tech note is the intent, periodically summarized in the cute generalizations at the head of each sub-topic. It's true that the dialog manager is not an interface. I can think of at least two general reasons which for this which aren't obvious from the tech note. 1) The dialog manager might encourage modality. This is mostly an intuition on my part. But if dialog-ing is too easy, it will be too tempting to fall back on it instead of designing a proper modeless environment. 2) The dialog manager, though extensible, has some, I'll say, "encouraged" limits. You might be encouraged to design a lame interface using existing controls and items, simply because it's so easy to do rather than sticking in an item draw proc and an event filter and thus and so. Granted, these two points assume you aren't being extra vigilant, as all UI designers should be. And they pretty much assume, as well, that you're capable of allowing yourself to make make silly design mistakes. But I've seen more than one program from an otherwise good designer use the dialog manager where it shouldn't. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
grh@rhi.hi.is (Gisli Runar Hjaltason) (05/23/91)
In <3174@krafla.rhi.hi.is> I write: >I am planning to write a kind of layout manager that is a superset of the >dialog manager and the layouts of 4th Dimension. [...] I'm not entirely correct when I say that my SuperDialogs (that's the current name of it) are a superset of 4th Dimension's layouts. What's right is that I will include those features of 4D layouts that I think are nice, but the SD's will not be limited to that. I plan that the package will have the ability to list a number of data records at once, as well as print them. I think I will use MPW Pascal to code SD, but any MPW compiler will be able to use it, and I think MPW object files can be converted to THINK's format. -- ============================================================================== Gisli R. Hjaltason grh@rhi.hi.is Iceland
grh@rhi.hi.is (Gisli Runar Hjaltason) (05/23/91)
I am planning to write a kind of layout manager that is a superset of the dialog manager and the layouts of 4th Dimension. If someone is interested I could post the specification here when I have it ready (soon) and the code (with possible changes in specification) later into comp.binaries.mac. What do you say??? -- ============================================================================== Gisli R. Hjaltason grh@rhi.hi.is Iceland