es2q+@andrew.cmu.edu (Erik Warren Selberg) (11/19/89)
I'm having two weird problems using an LDEF... the first one is that it doesn't seem to respond to an undate event.... when I select the window, the scroll bar and all that are updated, but I can't click on it or anything. However, when I do move the window or something, it's fine. Sort of like a second-activation deal. HALP! -- btw, I'm using a modified TWINDOW and TList in LSP 2.0. #2: this is more of a "can I?" question -- can I access a pointer in an LDEF? basically, I'd like to make a pointer and put the (ord4(ptr(xxx)) into the list data, and then use it in the LDEF. Can I do this? How??? Erik ...searching for "help .sig" on andrew....
tim@hoptoad.uucp (Tim Maroney) (11/20/89)
In article <kZNOPna00WB7BJkkoy@andrew.cmu.edu> es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >I'm having two weird problems using an LDEF... the first one is that it >doesn't seem to respond to an undate event.... when I select the window, the >scroll bar and all that are updated, but I can't click on it or anything. > However, when I do move the window or something, it's fine. Sort of >like a second-activation deal. HALP! -- btw, I'm using a modified TWINDOW >and TList in LSP 2.0. I've written a lot of LDEFs, and I don't remember seeing that problem. Could you describe it a bit more clearly? I'm especially puzzled about how moving the window could make a difference, since it doesn't do anything to the window contents. Vague phrases like "the scroll bar and all that" and "move the window or something" are not all that helpful. Could you give a more precise description? >#2: this is more of a "can I?" question -- can I access a pointer in an >LDEF? basically, I'd like to make a pointer and put the (ord4(ptr(xxx)) >into the list data, and then use it in the LDEF. Can I do this? How??? Sure. There are two fields in a ListRec you could use. There's a refCon and a userHandle. You could stash a pointer or handle into either one to communicate between the application and the LDEF. I recommend using the refCon. Note that you have to have both sides agree on the usage conventions, so you couldn't use this for a replacement LDEF 0 or anything similar. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "God must be a Boogie Man." -- Joni Mitchell
es2q+@andrew.cmu.edu (Erik Warren Selberg) (11/21/89)
ok... list bummer revisited: I'm using a home-made list object (TList) which has all the calls I want to make imbedded, along with an internal list:listHandle; data object. The problem is during a normal event, when I get an update for the window, the window itself updates, and the scroll bars hilight and the previously selected cell is once again selected as normal. The only problem is that the list won't accept any clicks... it's as if the Mac suddenly decided to stop accepting them. I am using a simple LDEF that looks sort of like the one in StandardGet/Put DLOGs... with a small icon out front, and then the text... the only difference being that I don't hilight the icon. BTW: in terms of the using ptrs in a list def, you aren't quite understanding (although I might just have got a clue on how to do it another way). What I want to do is pass each pointer in a linked list (all the data) to the list so it can handle it. I was thinking along the lines of putting the pointer address in the cell (so each entry would be 4 bytes long, but that crapped out). Is there any other way to do this, or would I be stuck putting it into the refCon and using a list reference type thing for the data? BergerMan
tim@hoptoad.uucp (Tim Maroney) (11/22/89)
In article <IZO=5Mm00XcAM7xkIZ@andrew.cmu.edu> es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >ok... list bummer revisited: I'm using a home-made list object (TList) >which has all the calls I want to make imbedded, along with an internal >list:listHandle; data object. The problem is during a normal event, when >I get an update for the window, the window itself updates, and the >scroll bars hilight and the previously selected cell is once again >selected as normal. The only problem is that the list won't accept any >clicks. I can't solve this, but I can suggest some things to look at that might help you solve it. (1) Is LClick getting called? If so, is it getting passed an appropriate click location? Is the port set to the list's port when you call LClick? You can find all this out by placing a debugger breakpoint. (2) Do clicks work on the scroll bar, but not on the list body? If so, it is very likely some sort of problem with the way your LDEF is handling hiliting. If not, it is very likely some sort of problem with the way you are calling LClick. (3) Despite the visual appearance of the list, is selection actually being done? This could indicate a clipping problem. In general, I have found that it is often a bad idea to mess with clipping in an LDEF, but if you do, be sure to restore the old state on exit. You can tell whether selection is actually being done correctly a gfew different ways. Given your description of behavior, I would expect the best way would be to replicate the problem, click on an unselected cell, hide the window behind another window, then bring it back to the front and see if the cell you clicked is hilited. >BTW: in terms of the using ptrs in a list def, you aren't quite >understanding (although I might just have got a clue on how to >do it another way). What I want to do is pass each pointer in a linked >list (all the data) to the list so it can handle it. I was thinking >along the lines of putting the pointer address in the cell (so each >entry would be 4 bytes long, but that crapped out). Is there any other >way to do this, or would I be stuck putting it into the refCon and using >a list reference type thing for the data? Uh -- I'm afraid I'm still not clear on this. What is the problem with putting the pointers from your linked list into the cell, and having your LDEF pull them out and dereference them? That ought to work fine. What do you mean, it crapped out? If for some reason you just can't do this, then put the header of the linked list in your list's refCon, and have all the cells be empty. Then your LDEF can easily find its data just by iterating down the list based on the cell index. If it's a one-column list, then just go to list entry number cell.v. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every institution I've ever been associated with has tried to screw me." -- Stephen Wolfram
es2q+@andrew.cmu.edu (Erik Warren Selberg) (11/26/89)
ok, list bummers revised:
what appears to be happening is that my DoContentClick() routine isn't
handling the mouse position correctly. what I'm doing is passing the
FrontWindow and event to the procedure, which is coded thus:
procedure DoContentClick (window: windowPtr;
theEvent: eventRecord);
var
tempFile: TFileList;
editFile: TFile;
dataLen: integer;
dummy: boolean;
theCell: cell;
begin
if IsAppWindow(window, tempFile) then
begin
GlobalToLocal(theEvent.where);
if PtInRect(theEvent.where, tempFile.lWindow^.portRect) &
tempFile.lList.click(theEvent.where, TheEvent.Modifiers) then
begin
editFile := tempFile.lList.Get(false, theCell);
if editFile <> nil then
begin
dummy := editFile.edit;
tempFile.lList.SetCellInfo(editFile);
editFile.Verify(tempFile.lList);
end;
end;
end;
end;
an explanation: IsAppWindow() returns true if the window is mine, and
returns an object in tempFile which contains all the stuff I want to play with.
tempFile.lWindow is a windowPtr.
tempFile.lList.lClick is simply a call to LClick which uses theEvent.where
and theEvent.modifiers, as well as a local list:listHandle variable.
the problem seems to be that either PtInRect isn't returning true when it's
supposed to, or LClick isn't clicking. I've tried making PtInRect use a
variable gpt that's equal to LocalToGlobal(theEvent.where), as well as passing
countless variations of GlobalToLocal and LocalToGlobal mutations to
both procedures, but both manage to screw up. Any ideas?
Eriktim@hoptoad.uucp (Tim Maroney) (11/29/89)
In article <sZPrPru00WB_ERlkgB@andrew.cmu.edu> es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >ok, list bummers revised: >what appears to be happening is that my DoContentClick() routine isn't >handling the mouse position correctly. what I'm doing is passing the >FrontWindow and event to the procedure, which is coded thus: > > begin > GlobalToLocal(theEvent.where); > if PtInRect(theEvent.where, tempFile.lWindow^.portRect) & >tempFile.lList.click(theEvent.where, TheEvent.Modifiers) then > begin > > end; > end; > >the problem seems to be that either PtInRect isn't returning true when it's >supposed to, or LClick isn't clicking. I've tried making PtInRect use a >variable gpt that's equal to LocalToGlobal(theEvent.where), as well as passing >countless variations of GlobalToLocal and LocalToGlobal mutations to >both procedures, but both manage to screw up. Any ideas? Both the points should be in local coordinates. However, notice that GlobalToLocal works with references to the curent port, not with respect to the front window. Your comments about how moving the window would make it work lead me to believe that the enclosing code is *not* doing a SetPort to the FrontWindow except in certain circumstances like dragging the window. If you were not setting the correct port before going into the routine shown above, that would explain your problems. Try putting in a "GetPort(save); SetPort(window);" at the beginning of your routine and a "SetPort(save);" at the end (and declare "save:GrafPtr") and see if this makes a difference. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"
es2q+@andrew.cmu.edu (Erik Warren Selberg) (11/30/89)
a SetPort, eh? hm.... I do call SelectWindow, which I assumed called SetPort. Is this not right (if is isn't, I do believe I found the bug!). <sigh> ------------------/ Megalo Erik \-------------------- GEnie: E.SELBERG | Selberg | CIS: 71470,2127 Delphi: LORDERIK | lost in | Fido: 129/107 BBS: 412 268 8974 | Andrew! | MacList: 6009/1 ------------------\ help! help! /-------------------- ...I'm being confused at CMU!
oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/30/89)
My pet peeve with the list manager is the thing scrolls to fast for simple lists on a fast machine. To fix this, I change the contrlProc field of my scroll bar to a handle to a jump instruction to a routine that delays if necessary, then dispatches off to the real control definition procedure. I wisk Apple would sanction a scrollbar CDEV that would provide this control in every program. I could write such a thing, but it would just be another hack without Apple's endorsement. > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
tecot@Apple.COM (Ed Tecot) (11/30/89)
In article <32885@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >My pet peeve with the list manager is the thing scrolls to fast for simple >lists on a fast machine. To fix this, I change the contrlProc field of my >scroll bar to a handle to a jump instruction to a routine that delays if >necessary, then dispatches off to the real control definition procedure. I >wisk Apple would sanction a scrollbar CDEV that would provide this control >in every program. I could write such a thing, but it would just be >another hack without Apple's endorsement. Your wish is my command. _emt
tim@hoptoad.uucp (Tim Maroney) (12/05/89)
In article <cZR3Kx600XoaM2vUYR@andrew.cmu.edu> es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >a SetPort, eh? hm.... I do call SelectWindow, which I assumed called >SetPort. Is this not right (if is isn't, I do believe I found the >bug!). <sigh> I thought *I* found the bug.... Anyway, SelectWindow doesn't do a SetPort. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "A book is the product of a contract with the Devil that inverts the Faustian contract, he'd told Allie. Dr Faustus sacrificed eternity in return for two dozen years of power; the writer agrees to the ruination of his life, and gains (but only if he's lucky) maybe not eternity, but posterity, at least. Either way (this was Jumpy's point) it's the Devil who wins." -- Salman Rushdie, THE SATANIC VERSES
thecloud@dhw68k.cts.com (Ken McLeod) (12/07/89)
In article <36883@apple.Apple.COM> tecot@Apple.COM (Ed Tecot) writes: >In article <32885@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >>My pet peeve with the list manager is the thing scrolls to fast for simple >>lists on a fast machine. To fix this, I change the contrlProc field of my >>scroll bar to a handle to a jump instruction to a routine that delays if >>necessary, then dispatches off to the real control definition procedure. I >>wisk Apple would sanction a scrollbar CDEV that would provide this control >>in every program. I could write such a thing, but it would just be >>another hack without Apple's endorsement. > >Your wish is my command. > > _emt Such a "scrollbar CDEV that provides this control in every program" already exists; in fact, it passed through comp.binaries.mac not more than 2 months ago. It's called "Scroll Limit"; current version is 1.1. Things would certainly be different if everyone had to obtain Apple's endorsement before writing a piece of software! :-) -ken -- ========== ....... ============================================= Ken McLeod :. .: UUCP: ...{spsd,zardoz,felix}!dhw68k!thecloud ========== :::.. ..::: INTERNET: thecloud@dhw68k.cts.com //// =============================================
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/08/89)
In article <28237@dhw68k.cts.com> thecloud@dhw68k.cts.com (Ken McLeod) writes: > Things would certainly be different if everyone had to obtain Apple's >endorsement before writing a piece of software! :-) I'm not asking Apple's permission to write it, I'm asking Apple to include it in the system 7 release disks. Without that, it is just another forgettable hack.
es2q+@andrew.cmu.edu (Erik Warren Selberg) (12/08/89)
(wish I could figure out how to quote with VUI...) anyway: I was having a problem not calling SetPort() with SelectWindow. I now do, problem still remains. Therefore, sorry Tom, *YOU* didn't find the bug. any other ideas? ARGH! ------------------/ Megalo Erik \-------------------- GEnie: E.SELBERG | Selberg | CIS: 71470,2127 Delphi: LORDERIK | lost in | Fido: 129/107 BBS: 412 268 8974 | Andrew! | MacList: 6009/1 ------------------\ help! help! /-------------------- ...I'm being confused at CMU!
billkatt@mondo.engin.umich.edu (billkatt) (12/09/89)
In article <33099@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <28237@dhw68k.cts.com> thecloud@dhw68k.cts.com (Ken McLeod) writes: >> Things would certainly be different if everyone had to obtain Apple's >>endorsement before writing a piece of software! :-) > >I'm not asking Apple's permission to write it, I'm asking Apple to include >it in the system 7 release disks. Without that, it is just another >forgettable hack. I've heard from a reputable source (a friend who worked in DeAnza 3 at Apple over the summer), that there is an equivalent in system 7. -Steve