jimm@amiga.UUCP (Jim Mackraz) (12/17/87)
:: Regarding string gadgets, and the use of ActivateGadget(). The lowdown is this here: ActivateGadget() will fail if conditions are not IDEAL at the time it is called. This includes: the window for the gadget is active, it's requester (if applic.) is active, menus aren't in use, other gadgets not in use (I think), propgadget not in use, and so on. OpenWindow() is synchronous; it won't return until the window is set up, but if you set the ACTIVATE flag, the activation of the window will not happen until Intuition has had a chance to run as the input.device, since it is only then that it can handle activation changes (good reasons). SO, OpenWindow() normally returns with the window INACTIVE. Calling a Delay(5L) to let things sort out is kind of bad, especially since a truer alternative is available (you could get screwed if there is a lot of blitter activity, I think). What you want to do is wait until you get your first ACTIVEWINDOW message from Intuition, then you have a good shot at getting the gadget active. Clearly, there are lots of edge conditions (users banging on gadgets, IHelp, other programs opening windows, and so on) which might cause ActivateGadget() to fail. Be sure that you can handle this. You might change a message, or try to Activate it again after something happens. Watch the Workbench Rename gadget work as you click around. Note that if you have a Requster string gadget, you need to be even trickier, since you need to wait for both ACTIVEWINDOW and REQACTIVE. And that's the lowdown. 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.
ali@navajo.UUCP (Ali Ozer) (12/18/87)
[] [Posting this for Stuart Ferguson (shf@Solar.Stanford.EDU) -Ali] In article <1972@amiga.amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: |Regarding string gadgets, and the use of ActivateGadget(). | |The lowdown is this here: | |...OpenWindow() normally returns with the window INACTIVE. Calling a |Delay(5L) to let things sort out is kind of bad, especially since Guilty. I recomended that fix. |a truer alternative is available (you could get screwed if there is |a lot of blitter activity, I think). What you want to do is wait |until you get your first ACTIVEWINDOW message from Intuition, then |you have a good shot at getting the gadget active. The sequence I was using was: Request (req, win); Delay (5L); ActivateGadget (gad, win, req); <message wait & process loop> It didn't work without the Delay(). I've since gone back and changed the above to: Request (req, win); <message wait loop> { ... case REQSET: ActivateGadget (gad, win, req); break; ... } This works fine, and is obviously preferable from an aesthetic standpoint. Thanx for the advice everyone! |And that's the lowdown. |Jim Mackraz, I and I Computing Maybe you can help with this new problem, also dealing with the dreaded String Gadgets. I have a string gadget in a requester with RELVERIFY set. The user selects this gadget and enters a value by pressing return. The program then adjusts this value to fit the parameters, writes the new value back into the string gadget buffer and refreshes the gadget. Thusly: <processing messages from an open requester> case GADGETUP: ... case STR_ID: sscanf (buffer, "%d", &val); /* read out the string buffer */ val = val%16; /* adjust value to correct range */ sprintf (buffer, "%d", val); /* update gadget */ RefreshGList (&strgad, win, req, 1L); break; ... The problem is that if I select this gadget, type in a value and press return, the new value gets printed into the string gadget, but the cursor is still on! In any normal string gadget if I press return the cursor disapears, but in this one the cursor is still rendered. The string gadget, however, is NOT active. To make the cursor go away, I have to select the gadget *again* and de-select it by clicking somewhere else (not by pressing return). This simply won't do. Any ideas about how to fix this? Stuart Ferguson (shf@Solar.Stanford.EDU) Action by HAVOC
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/18/87)
In article <1972@amiga.amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: >Note that if you have a Requster string gadget, you need to be even >trickier, since you need to wait for both ACTIVEWINDOW and REQACTIVE. > ^^^^^^^^^ Wow, jimm! Is this a change in 1.3? Or are you doing some new kind of drugs? :-) Jim, of course, meant REQSET. Didn't you, Jim. The ACTIVEWINDOW information was very helpful. I didn't know that. Thanks. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{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
chas@gtss.UUCP (Charles Cleveland) (12/19/87)
In article <2030@navajo.UUCP> ali@navajo.stanford.edu (Ali Ozer) writes:
:-(
:-( <processing messages from an open requester>
:-( case GADGETUP:
:-( ...
:-( case STR_ID:
:-( sscanf (buffer, "%d", &val); /* read out the string buffer */
:-( val = val%16; /* adjust value to correct range */
:-( sprintf (buffer, "%d", val); /* update gadget */
:-( RefreshGList (&strgad, win, req, 1L);
:-( break;
:-( ...
:-(
I once did something somewhat similar and didn't have any problems.
There are enough differences so that I'm unsure my experience applies though.
Like a good little scout, I was careful to use Remove/AddGadget() around the
places where I was making changes in the gadget and you don't seem to have
included that in your example code. A possibility?
--
-Life would be so much easier if we could just look at the source code.-
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332
UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edushf@well.UUCP (Stuart H. Ferguson) (01/02/88)
The Return of the String Gadget ... part six ...
The story so far:
I'm processing IntuiMessages from a requester in a loop which has some code
in it like this
case GADGETUP:
...
case STR_ID:
sscanf (buffer, "%d", &val);
val = val % 16;
sprintf (buffer, "%d", val);
RefreshGList (&strgad, win, req, 1L);
break;
...
This is supposed to update the value in a string gadget buffer and refreash
the string gadget. It doesn't work.
The Guy in The Cape suggests that I need to insert a RemoveGadget() and
AddGadget() before the sscanf() and after the sprintf(), respectively. He
points out that this is mentioned in the AutoDocs. Sure enough, it is
mentioned in the AutoDocs and seems like a sensible thing to do but for one
small detail. It doesn't work. My Amiga goes for a holiday and doesn't
leave a forwarding address (lock up).
I suspect that this happens because this is a Requester gadget, and the
Add/RemoveGadget() functions are specifically for *Window* gadgets.
RemoveGadget() says that it will remove a REQGADGET and it does seem to
remove it and even returns a reasonable position. But when I call the
AddGadget() function it never returns.
So, the question remains, what is the correct way to update a string gadget
in a requester?
Stuart Ferguson
Action by HAVOC