tas@mtuxo.att.com (XMPC2-T.SKROBALA) (09/25/88)
I would like to see the contents of one of my windows scroll continouously as I slide a prop gadget up and down, rather than just get one change when I finish let go of the select button. Preferences and Manx's SDB give this "instant feedback", and it's nice. I thought of two ways to accomplish this, and neither seems to work. One way is to set the prop-gadget's FOLLOWMOUSE flag and check the gadget's PropInfo structure every time I get a MOUSEMOVE message; the other way is to check the PropInfo each time I get an INTUITUCKS message. The problem is that, as soon as I press the mouse's select button, all MOUSEMOVE and INTUITICKS messages appear to be suspended until I release the button (at which point I get a flood of MOUSEMOVE messages). I have tried various combinations of GADGIMMEDIATE, RELVERIFY, and FOLLOWMOUSE in the gadget's Activation field, and I reply to all messages. Am I missing something? If I ever do succeed in getting continuous messages, is it reasonable to expect the PropInfo structure to be updated continuously? Is there another way to get the desired effect? Thanks, Tom Skrobala AT&T Bell Laboratories mtuxo!tas 201-957-5446
Sullivan@cup.portal.com (09/28/88)
> >I would like to see the contents of one of my windows scroll continouously >as I slide a prop gadget up and down, rather than just get one change >when I finish let go of the select button. Preferences and Manx's SDB >gadget's Activation field, and I reply to all messages. Am I missing >something? If I ever do succeed in getting continuous messages, is it >reasonable to expect the PropInfo structure to be updated continuously? >Is there another way to get the desired effect? > >Thanks, >Tom Skrobala AT&T Bell Laboratories mtuxo!tas 201-957-5446 Sounds like your gadgets are changing the screen (as well they should) but since Intuition now has a lock on the front bitmap (to animate the gadget) nothing else in the window can update. Thus you don't get any of the messages you are waiting for after the first time you wait on anything else that would update the screen (like printing a new list of lines). If these assumptions are correct then what you must do, is to make your scroll bar something other than a gadget, and animate it yourself (by following the mouse...) That way your main task will have the lock neccessary to do both of the screen updates. Alternatively, you could violate the lock (since you know what the user is doing anyway,) and write to the screen bitmap directly. (This could really mess up the screen if you don't call window to front first, or if a requestor comes up, but hey, if you are planning on taking over the machine anyway, who cares? Think? Who Me? I hack, sometimes it's more fun to see how many different ways your code can crash the machine. :-) (PLEASE don't take that seriously.) -Sullivan Segall (still looking for a 68881 that can be piggy-backed on a 68000) _____________________________________________________________ /V\ My opinions are guaranteed to be worth at least what you ' paid for them. If you are dissatisfied, please return them to the nearest vendor for a full and prompt refund. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
eric@cbmvax.UUCP (Eric Cotton) (09/29/88)
In article <2877@mtuxo.att.com> tas@mtuxo.att.com (XMPC2-T.SKROBALA) writes: >I would like to see the contents of one of my windows scroll continouously >as I slide a prop gadget up and down, rather than just get one change >when I finish let go of the select button. Preferences and Manx's SDB >give this "instant feedback", and it's nice. I thought of two ways to >accomplish this, and neither seems to work. One way is to set the >prop-gadget's FOLLOWMOUSE flag and check the gadget's PropInfo structure >every time I get a MOUSEMOVE message; the other way is to check the >PropInfo each time I get an INTUITUCKS message. The problem is that, as >soon as I press the mouse's select button, all MOUSEMOVE and INTUITICKS >messages appear to be suspended until I release the button (at which >point I get a flood of MOUSEMOVE messages). I have tried various >combinations of GADGIMMEDIATE, RELVERIFY, and FOLLOWMOUSE in the >gadget's Activation field, and I reply to all messages. Am I missing >something? If I ever do succeed in getting continuous messages, is it >reasonable to expect the PropInfo structure to be updated continuously? >Is there another way to get the desired effect? Preferences sets the FOLLOWMOUSE, GADGIMMEDIATE, RELVERIFY flags (for the color sliders, for example) and checks the PropInfo structures on each MOUSEMOVE. So, it seems that you are on the right track. Also, beware of quick buildup of MOUSEMOVE messages. -- Eric Cotton Commodore-Amiga (215) 431-9100 1200 Wilson Drive {rutgers|allegra}!cbmvax!eric West Chester, PA 19380 "I don't find this stuff amusing anymore."
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/30/88)
In article <9515@cup.portal.com> Sullivan@cup.portal.com writes: >> >>I would like to see the contents of one of my windows scroll continouously >>as I slide a prop gadget up and down, rather than just get one change >>when I finish let go of the select button. Preferences and Manx's SDB > >Sounds like your gadgets are changing the screen (as well they should) but >since Intuition now has a lock on the front bitmap (to animate the gadget) >nothing else in the window can update. more untruths about Intuition and gadgets deleted.... Intuition does not keep any lock on the window (or any of it's parts) for long periods of time like that. The problem is that you aren't getting the messages when you expect them. You must not have your window or gadget set up properly. When you want to get mousemoves from a gadget, you must make sure the gadget AND the window's IDCMP stuff is set up properly. All this is from memory (boy I need to get some RKM's for work, or Net access at home)... To set things up: 1. Set up the FOLLOWMOUSE and GADGIMMEDIATE flags. You can set RELVERIFY if you want to stop getting MOUSEMOVES when the mouse is outside the potentiometer's container. If you have IDCMP set up properly, this should give you GADGETDOWN, MOUSEMOVES, and GADGETUP messages. 2. In the window, you must make sure the window flags and IDCMPFlags are set up properly. Make sure your NewWindow structure's Flags member has REPORTMOUSE set in it. If your program always wants to see MOUSEMOVES, you should set the MOUSEMOVES flag in the NewWindow structure's IDCMPFlags. If you normally have your IDCMP set up to not receive MOUSEMOVES then when the user presses the potentiometer gadget, you should start to receive MOUSEMOVE message. They should stop once the user releases the mouse button (or go out of the potentiometer container and you have RELVERIFY set.) This is a long winded explanantion, but Sullivan seemed so far off base that I felt I should try to correct things. There is absolutely no need to go directly to the screen to do any rendering or simulate your own gadget stuff. Tom Skrobala (the original author) seemed to be getting mouse moves, but without more information, it's hard to know if they are associated with the potentiometer gadget, or just the window. From Tom: >>I have tried various >>combinations of GADGIMMEDIATE, RELVERIFY, and FOLLOWMOUSE in the >>gadget's Activation field, and I reply to all messages. Am I missing >>something? I think your in the right area..... email me if you continue to have problems. You might print out IDCMPFlags in your open window to see if intuition automagically turns on and off your MOUSEMOVE IDCMPFlags. If it doesn't then you might have to (but I doubt it.) >>If I ever do succeed in getting continuous messages, is it >>reasonable to expect the PropInfo structure to be updated continuously? Yes. >>Is there another way to get the desired effect? This is the right way. Using INTUITICKS is OK, but it is a waste. You would continue to receive and process INTUITICKS, even when the user does not move the mouse. Using FOLLOWMOUSE, you only process messages when you need to. >>Thanks, >>Tom Skrobala AT&T Bell Laboratories mtuxo!tas 201-957-5446 In article <9515@cup.portal.com> Sullivan@cup.portal.com writes: > >Think? Who Me? I hack, sometimes it's more fun to see how many different >ways your code can crash the machine. :-) (PLEASE don't take that seriously.) > > -Sullivan Segall Kinda hard not to... kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/01/88)
>In article <2877@mtuxo.att.com> tas@mtuxo.att.com (XMPC2-T.SKROBALA) writes: >>I would like to see the contents of one of my windows scroll continouously >>as I slide a prop gadget up and down, [ ... ] >>I thought of two ways to >>accomplish this, and neither seems to work. One way is to set the >>prop-gadget's FOLLOWMOUSE flag and check the gadget's PropInfo structure >>every time I get a MOUSEMOVE message; [ ... ] After having finished Yet Another G*d D*mn File Requester (can you tell I'm burning out), I can tell you that this works. >>The problem is that, as >>soon as I press the mouse's select button, all MOUSEMOVE and INTUITICKS >>messages appear to be suspended until I release the button (at which >>point I get a flood of MOUSEMOVE messages). [ ... ] It sounds to me like you have a bug in your processing loop (this is a stab in the dark). >>If I ever do succeed in getting continuous messages, is it >>reasonable to expect the PropInfo structure to be updated continuously? Yes. -------- In article <4875@cbmvax.UUCP> eric@cbmvax.UUCP (Eric Cotton) writes: >Preferences sets the FOLLOWMOUSE, GADGIMMEDIATE, RELVERIFY flags [ ... ] Why do you set RELVERIFY? I set just FOLLOWMOUSE and GADGIMMEDIATE and it works great. >Also, beware of quick buildup of MOUSEMOVE messages. A way around that: -------- while (msg = GetMsg (window -> UserPort)) { class = msg -> Class; ReplyMsg (msg); if (class == MOUSEMOVE) moveit = 1; : : } if (moveit) movethedamnthing (); -------- Good luck, guy. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
peter@sugar.uu.net (Peter da Silva) (10/01/88)
In article <9515@cup.portal.com>, Sullivan@cup.portal.com writes: > Sounds like your gadgets are changing the screen (as well they should) but > since Intuition now has a lock on the front bitmap (to animate the gadget) > nothing else in the window can update. I update sliding gadgets continually all the time. No problem. just make sure you have FOLLOWMOUSE set in the gadget. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
tas@mtuxo.att.com (XMPC2-T.SKROBALA) (10/02/88)
-- I've found the cause of my problem. Recall that I wanted to get MOUSEMOVE (and/or INTUITICKS) messages while I had the select button pressed down over a prop gadget, and I wasn't getting the messages until after I released the button. Well, I was setting gadget->Activation to GADGIMMEDIATE+FOLLOWMOUSE, which was correct, and the window's IDCMPFlags included MOUSEMOVE, also correct. But there was something in my code that was interfering with message reception. Every time I received an Intuition message, I was checking the window's validity within a LockIBase() / UnlockIBase() pair, and (I guess) Intuition had a lock on the semaphore that prevented LockIBase() from completing (and thus suspended my program's operation) as long as the gadget was still sliding around. As soon as I released the gadget, I got all the MOUSEMOVE messages that had been queueing up. When I remove the LockIBase() / UnlockIBase(), I get the MOUSEMOVE messages as the gadget slides, which is great. Thanks to all who offered their opinions and generally encouraged me to keep looking. Now comes the followup question. I have the LockIBase() there because all my windows share a common IDCMP port, and I want to make sure that I don't process any messages left over from windows that have been closed, so I check any incoming message's IDCMPWindow to make sure that it still exists. I'm not terribly satisfied with this approach (especially now that it's obviously causing me problems), and I've gotten the idea here that there is a way to flush all of a window's pending messages when it is closed. Is this as simple as installing a GetMsg() loop before CloseWindow(), or is there more to it? Thanks again, Tom Skrobala AT&T Bell Laboratories mtuxo!tas 201-957-5446
peter@sugar.uu.net (Peter da Silva) (10/03/88)
In article <2937@mtuxo.att.com>, tas@mtuxo.att.com (XMPC2-T.SKROBALA) writes: > (especially now that it's obviously causing me problems), and I've gotten > the idea here that there is a way to flush all of a window's pending messages > when it is closed. Is this as simple as installing a GetMsg() loop before > CloseWindow(), or is there more to it? I don't know. I was trying to do the same thing with a GetMsg/ReplyMsg loop just before I closed any window, but I still got occasional gurus on closing a window. I finally gave up and went back to multiple IDCMPs. Anyone have a code fragment that is safe and has no windows where a message can get sent to a bogus port? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/03/88)
In article <2937@mtuxo.att.com> tas@mtuxo.att.com (XMPC2-T.SKROBALA) writes: > Thanks to all who offered their opinions and generally encouraged me to > keep looking. Now comes the followup question. I have the LockIBase() > there because all my windows share a common IDCMP port, and I want to > make sure that I don't process any messages left over from windows that have > been closed, so I check any incoming message's IDCMPWindow to make sure > that it still exists. First, I hope you null out your Window pointers after you close the windows, second when you get a message there isn't any need to call LockIBase() because you aren't going to do anything yet that will affect a window. So when you get a message, copy it, reply to it, and then check to see if it's window pointer matches any of your open window pointers. If you keep them in an array this is pretty easy. If it doesn't you just ignore the message. If it does, then you know that the window is still open so you go ahead and process it appropriately. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/03/88)
In article <2738@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > I don't know. I was trying to do the same thing with a GetMsg/ReplyMsg loop > just before I closed any window, but I still got occasional gurus on closing > a window. I finally gave up and went back to multiple IDCMPs. Note that there is a bug in DeleteLayer() or some such name in the ROM that can cause occasional crashes when a window is closed. The bug is that Layers frees some memory, and then uses it. Thus typically you would tickle this bug when closing windows while another task was doing memory allocations. The program SetPatch on the 1.3 disks patches this bug. > Peter da Silva `-_-' peter@sugar.uu.net --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/04/88)
In article <2937@mtuxo.att.com> tas@mtuxo.att.com (XMPC2-T.SKROBALA) writes: >I have the LockIBase() >there because all my windows share a common IDCMP port, and I want to >make sure that I don't process any messages left over from windows that have >been closed, so I check any incoming message's IDCMPWindow to make sure >that it still exists. I'm not terribly satisfied with this approach >(especially now that it's obviously causing me problems), and I've gotten >the idea here that there is a way to flush all of a window's pending messages >when it is closed. Is this as simple as installing a GetMsg() loop before >CloseWindow(), or is there more to it? > You want the routine CloseWindowSafely(): -------- /* CloseWindowSafely() * This module should be used whenever you are sharing an IDCMP * message port with more than one window. Rather than calling CloseWindow(), * you should use CloseWindowSafely(). This will keep Intuition from * Guru Meditation, and thus is considered a good thing. You should still * use CloseWindow for the very last window you close. * The reason this is needed is because Intuition will re-claim * any outstanding messages for a window when the window is closed. But... * it can't take them out of your message port. Thus, you will receive * invalid messages and bad things will happen. Very bad things. * This code is a slightly condensed version of the same routine * written by Neil Katin of Amiga for the April '86 Commodore Developers * Newsletter, Amiga Mail (tm). */ #include <exec/types.h> #include <intuition/intuition.h> void CloseWindowSafely (win) register struct Window *win; { register struct IntuiMessage *msg; register struct IntuiMessage *succ; register struct MsgPort *mp = (struct MsgPort *) win -> UserPort; Forbid (); msg = (struct IntuiMessage *) mp -> mp_MsgList.lh_Head; while (succ = (struct IntuiMessage *) msg -> ExecMessage.mn_Node.ln_Succ) { if (msg -> IDCMPWindow == win) { Remove (msg); ReplyMsg (msg); } msg = succ; } win -> UserPort = NULL; ModifyIDCMP (win, 0L); Permit (); CloseWindow (win); } -------- Enjoy. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
Sullivan@cup.portal.com (10/05/88)
>>> >>>I would like to see the contents of one of my windows scroll continouously >>>as I slide a prop gadget up and down, rather than just get one change >>>when I finish let go of the select button. Preferences and Manx's SDB >> >>Sounds like your gadgets are changing the screen (as well they should) but >>since Intuition now has a lock on the front bitmap (to animate the gadget) >>nothing else in the window can update. > > more untruths about Intuition and gadgets deleted.... > >Intuition does not keep any lock on the window (or any of it's parts) >for long periods of time like that. The problem is that you aren't >getting the messages when you expect them. You must not have your >window or gadget set up properly. > When in doubt experiment. Intuition does indeed keep locks on windows for long periods of time like that. (Although it doesn't in the case of a slider bar. That one I hadn't experimented with.) The drag and size gadgets both lock the entire window which they are in (an admittedly reasonable course of action. Although one could unlock periodically for a moment and sleep, to allow other processes to update their windows. Right clicking also locks the front window if pull down menus have been defined (also for obvious reasons.) It pleases me to no end that playing with gadgets does not. Another thing done right in the O/S. Maybe I'll get around to writing a program that doesn't steal the entire machine one of these days. Not that I don't like the O/S, I just don't have a whole lot of use for it in my own programs. -Sullivan Segall _____________________________________________________________ /V\ Sully set the example: to fly without moving. We shall ' learn to soar on wings of thought. And the student will surpass the teacher. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
kevin@amdahl.uts.amdahl.com (Kevin Clague) (10/06/88)
In article <9746@cup.portal.com> Sullivan@cup.portal.com writes: >>>> >>>>I would like to see the contents of one of my windows scroll continouously >>>>as I slide a prop gadget up and down, rather than just get one change >>>>when I finish let go of the select button. Preferences and Manx's SDB >>> >>>Sounds like your gadgets are changing the screen (as well they should) but >>>since Intuition now has a lock on the front bitmap (to animate the gadget) >>>nothing else in the window can update. >> >> more untruths about Intuition and gadgets deleted.... >> >>Intuition does not keep any lock on the window (or any of it's parts) >>for long periods of time like that. The problem is that you aren't >>getting the messages when you expect them. You must not have your >>window or gadget set up properly. >> >When in doubt experiment. Intuition does indeed keep locks on windows >for long periods of time like that. (Although it doesn't in the case >of a slider bar. That one I hadn't experimented with.) The drag and >size gadgets both lock the entire window which they are in (an admittedly >reasonable course of action. Although one could unlock periodically for >a moment and sleep, to allow other processes to update their windows. >Right clicking also locks the front window if pull down menus have been >defined (also for obvious reasons.) For moving and resizing of windows, as well as pulling down menus, Intuition locks the layers of ALL the windows within a given screen. It must do this to stop other rendering from happening. But as you mentioned not for sliding gadgets. Had the original poster gone straight to the screen's bit map to do the gadget simulation (rendering and such), they would have bypassed all the layers protection, and possibly trashed other windows (or menus) displays. The kinds of things you suggested as possible solutions to the problem can be used, but should only be used as a last resort. The people who designed the Amiga were very far sighted and have built the OS around multitasking. We should do the best we can to write software that works in concert with the facilities they have provided. >Maybe I'll get around to writing a program that doesn't steal the entire >machine one of these days. Not that I don't like the O/S, I just don't >have a whole lot of use for it in my own programs. This explains your insight into ways to circumvent the problem. I guess your original suggestions were not wrong, just inappropriate for the the problem at hand. They were helpful in solving the problem, so this is good. Kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
jimm@amiga.UUCP (Jim Mackraz) (10/11/88)
In article <9746@cup.portal.com> Sullivan@cup.portal.com writes:
)When in doubt experiment. Intuition does indeed keep locks on windows
)for long periods of time like that. (Although it doesn't in the case
)of a slider bar. That one I hadn't experimented with.)
)The drag and
)size gadgets both lock the entire window which they are in (an admittedly
)reasonable course of action. Although one could unlock periodically for
)a moment and sleep, to allow other processes to update their windows.
Actually, Intuition locks *all* the windows (LockLayers), the primary
reason being to keep window rendering from colliding with the drag/size
window frame. So, it can't let other programs run without doing some
special deal with the window frame (which I think is NWI: Not Worth It)
save/restore.
)Right clicking also locks the front window if pull down menus have been
)defined (also for obvious reasons.)
Again, LockLayers: all windows. Same reason: menus, like size/drag frame,
are rendered directly into the screen rastport so must be arbitrated.
Note that this arbitration only works on windows so if you want menus
but render directly into you screen you need another arbitration technique,
which is what MENUVERIFY is all about.
)It pleases me to no end that playing
)with gadgets does not. Another thing done right in the O/S.
It is particularly gratifying when people notice and appreciate the hard
parts.
By the way, in DropShadow2, one slider changes the shadow color (a few
LoadRGB4's) which is processor intensive. I found it helpful to crank
up my tasks priority while the gadget is in use. Note that it's easy
to check if the gadget is in use by testing its SELECTED bit (a technique
I'm not particulary pleased with but guaranteed to be supported).
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.