brsmith@cs.umn.edu (Brian R. Smith) (04/10/91)
I'm in the middle of porting a small application from sunview to xview, and I've come across this strange problem. I've got a command frame with a large number of check boxes, and four buttons; Done, Cancel, Reset, and Optimum. Done and Cancel are somewhat obvious, Reset turns all the check boxes on (the default), and Optimum sets each to a computed setting. Now here's the weird part: Whenever any of these four buttons is pressed and released the command frame is taken down. (XV_SHOW set to FALSE.) Even if there isn't a callback for that button. Is this supposed to happen? I can find no mention of it in O'Reilly volume 7 - which isn't to say it isn't there. It appears to happen consistently, so I am not sure if it's a bug or a feature. If it is supposed to work that way, how can I turn it off? Thoughts, anyone? -- Brian brsmith@cs.umn.edu
brsmith@cs.umn.edu (Brian R. Smith) (04/11/91)
In <1991Apr9.215503.20523@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >Now here's the weird part: Whenever any of these four buttons is >pressed and released the command frame is taken down. (XV_SHOW set to >FALSE.) Even if there isn't a callback for that button. >Is this supposed to happen? I can find no mention of it in O'Reilly >volume 7 - which isn't to say it isn't there. It appears to happen >consistently, so I am not sure if it's a bug or a feature. Apparently it's a feature. So, how do you circumvent it? Answer #1 Two different folks at sun (David Berry (dtb@Eng.sun.com) and Larry Wake (Larry.Wake@West.Sun.COM)) provided a simple answer. Just set the button's PANEL_NOTIFY_STATUS to XV_ERROR before returning from the notify procedure, and the command frame will be left up. I.E. (pasted right out of Larry Wake's note): void some_button_notify(item, event) Panel_item item; Event *event; { [... your code here ...] xv_set(item, PANEL_NOTIFY_STATUS, XV_ERROR, NULL); } This is what I'm using now. Answer #2 Force the push-pin in when you make the command frame. (Marc Ramsey (autodesk!sunra!marc@fernwood.mpk.ca.us) and Frame Hage (fhage@brainiac.rap.ucar.edu)) Larry Wake also pointed out that it IS indeed in the XVPM - bottom of page 148 and top of page 149. I had read that chapter, but missed that little tidbit completely... Thanks to all who replied. I wasn't expecting such a fast response. I got a working answer within an hour of my post... And to think some consider reading news a waste of time. Take care, -- Brian brsmith@cs.umn.edu
tom@elan.Elan.COM (Thomas Smith) (04/11/91)
From article <1991Apr9.215503.20523@cs.umn.edu>, by brsmith@cs.umn.edu (Brian R. Smith) [ - No relation]: > I've got a command frame with a large number of check boxes, and four > buttons; Done, Cancel, Reset, and Optimum. Done and Cancel are > somewhat obvious, Reset turns all the check boxes on (the default), > and Optimum sets each to a computed setting. > > Now here's the weird part: Whenever any of these four buttons is > pressed and released the command frame is taken down. (XV_SHOW set to > FALSE.) Even if there isn't a callback for that button. > > Is this supposed to happen? Yes, it's "supposed" to happen, but obviously isn't what you want. I have complained to Sun several times in the last couple of years about this interpretation of the OpenLook Style Guide, to no avail. It is built into XView to remove the window when any PANEL_BUTTON is pressed. It is particularly damaging when your particular "Do It" action in your dialog box encounters an error. In that case you want to leave the dialog box up so that the context of the error is still present for the user to see (and correct). > If it is supposed to work that way, how can I turn it off? Fortunately, it is easy to find the cause in the source (if you have it). In libxvol/panel/p_btn.c, you will find a function called "take_down_cmd_frame." Simply remove the body of the function. In fact, this function is the last global function in the file. Someone I know, who shall remain nameless, actually has located this function in the libxview.a library and inserted a sparc 'return-from-procedure' instruction at the beginning using adb! Nice to know there are some real (tm) programmers left... Hope this helps, Thomas Smith Elan Computer Group, Inc. (415) 964-2200 tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom
chuck@trantor.harris-atd.com (Chuck Musciano) (04/12/91)
In article <981@elan.Elan.COM>, tom@elan.Elan.COM (Thomas Smith) writes: > From article <1991Apr9.215503.20523@cs.umn.edu>, > by brsmith@cs.umn.edu (Brian R. Smith) [ - No relation]: > > Now here's the weird part: Whenever any of these four buttons is > > pressed and released the command frame is taken down. (XV_SHOW set to > > FALSE.) Even if there isn't a callback for that button. > > > > Is this supposed to happen? > > Yes, it's "supposed" to happen, but obviously isn't what you want. > I have complained to Sun several times in the last couple of years > about this interpretation of the OpenLook Style Guide, to no avail. > It is built into XView to remove the window when any PANEL_BUTTON > is pressed. > > > If it is supposed to work that way, how can I turn it off? > > Fortunately, it is easy to find the cause in the source (if you have it). > In libxvol/panel/p_btn.c, you will find a function called > "take_down_cmd_frame." Simply remove the body of the function. An easier solution is to set the PANEL_NOTIFY_STATUS attribute of the pressed button to XV_ERROR. This keeps the dialog up. Setting it to XV_OK (the default) will remove the dialog. There is a corresponding MENU_NOTIFY_STATUS attribute for menus and menu items that must be set when a menu is displayed in a dialog box. It remains to be seen if the 2.0 bug, wherein displaying a menu without making a selection always removes the panel no matter what you do, has been fixed in 3.0. I argued till I was blue in the face about this "feature" in XView. Many people in Sun agree that it is a bug, but apparently a few who disagree got their way. I would love to hear even one reason why it is felt that this behavior is the right behavior. The worst part about the bug is that new users typically explore a tool by opening the dialogs and simply pulling, but not selecting, each menu. Wham! The dialogs mysteriously disappear! They get a real warm feeling about OPEN LOOK at that point, let me tell you. Especially when you explain it is a bug, and they think, "hmmm, been using the system for about 45 seconds, and I've already hit a major bug. Great!" -- Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 729-3363 A good newspaper is never good enough, but a lousy newspaper is a joy forever. -- Garrison Keillor
openlook-request@openlook (04/12/91)
> Now here's the weird part: Whenever any of these four buttons is > pressed and released the command frame is taken down. (XV_SHOW set to > FALSE.) Even if there isn't a callback for that button. > This *is* supposed to happen. Unless you make your command frame pinnable and then put the pin in. Frank G.