rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) (10/10/88)
I have written a couple of custom definition procedures that I
need to use in a Desk Accessory, specificially, a couple of CDEFs and
a LDEF.
Since these resources must follow the DA around, I have given the
xDEFs the required IDs so they would belong to the DA. This causes a small
problem, because the procedures NewControl, and LNew are expecting
conventional resource IDs.
I tried to compute the resource ID of the xDEFs and get handles to
them, lock them down, and throw them into the ContrlDefProc fields of
the control records.
This does not work. So, I tried setting the SysHeap attribute of
each of the resources. This also did not work.
When the program tries to draw the lists, I get a SystemError of
ID 3 or 12.
Any ideas of what I need to do?
Thank you.
Rob Johnston.tim@hoptoad.uucp (Tim Maroney) (10/11/88)
In article <IXI3A1y00Uw90Fq0Vh@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes: > I have written a couple of custom definition procedures that I >need to use in a Desk Accessory, specificially, a couple of CDEFs and >a LDEF. > I tried to compute the resource ID of the xDEFs and get handles to >them, lock them down, and throw them into the ContrlDefProc fields of >the control records. You're trying too hard, at least for the lists. What is wrong with just passing the computed resource id to LNew? This works fine in the DA with a custom LDEF that I'm working on now. Changing the defproc after you initialize the control or list won't work, because the initialization hook in the defproc won't get called, and the entity has already been initialized as something else. > This does not work. So, I tried setting the SysHeap attribute of >each of the resources. This also did not work. Bad idea. Stay out of the system heap if you can. > When the program tries to draw the lists, I get a SystemError of >ID 3 or 12. That probably means you're putting a zero handle into the defproc field, since those errors are illegal instruction and unimplemented trap. From that, I suspect you are computing the wrong resource id. It should be easy enough to find that out using MacsBug or TMON or Jasik's debugger. If you're not used to twiddling bits, be careful. I answered a question for someone last week who was anding with a mask that cleared the bits he wanted set and vice versa. Looking in the Control Manager chapter, I notice that the variation code handling will prevent you from using the owned resource id directly. How unfortunate. In that case, you may have to stuff the resource handle in the defproc as you suggested (making sure with a debugger that it really does go in), then call the initialization hook yourself. A bit messy, but it ought to work. An alternative is to use a separate resource file; open it before creating the custom control, and then you can use a normal control definition id, outside the owned range. But only do this if your DA would have a data file of some sort anyway, otherwise it's a pain to the user. And observe the cautions about opening resource files in the Desk Manager chapter of Inside Mac. Fortunately, list definitions don't suffer from this variation code problem. You can use the computed resource id directly in a call to LNew. Oops, almost forgot to make a pointless attack on Apple software, sorry. Anyone else use the LClikLoop field of a list? Is it or is it not completely insane that this hook does not get passed any arguments, even the list handle clicked in? Bizarre. I have a religious opposition to most uses of global variables; this mandates their use, and in a messy way. Sigh. Let me know how this works out.... -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." - Virginia Woolf, "Mrs. Dalloway"