From owner-oi-users Mon Feb 20 05:35:14 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id FAA22189 for oi-users-outgoing; Mon, 20 Feb 1995 05:35:14 -0800 Received: from mxrelay.gmd.de (mxrelay.gmd.de [192.88.97.99]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id FAA22148 for ; Mon, 20 Feb 1995 05:35:04 -0800 Message-Id: <199502201335.FAA22148@freefall.cdrom.com> Received: from vm.gmd.de by mxrelay.gmd.de (SF for OpenVMS v1.0-alpha) with SMTP id 7B49ECDE ; Mon, 20 Feb 95 14:34:07 +0100 Received: from VM.GMD.DE by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 8216; Mon, 20 Feb 95 14:29:53 +0100 Received: from VMPROFS.ESOC.ESA.DE (NJE origin MAILER@ESOC) by VM.GMD.DE (LMail V1.2a/1.8a) with BSMTP id 0637; Mon, 20 Feb 1995 14:29:54 +0100 Received: from ESOC (NJE origin PWILLIAM@ESOC) by VMPROFS.ESOC.ESA.DE (LMail V1.2a/1.8a) with BSMTP id 0047; Mon, 20 Feb 1995 14:32:06 +0100 Comments: Converted from PROFS to RFC822 format by PUMP V2.2X Date: Mon, 20 Feb 95 14:32:03 EWT From: Peter Williams Subject: Creating Application Windows in an OI_add_timeout callback To: Sender: oi-users-owner@FreeBSD.org Precedence: bulk Hello OI users, We are currently experiencing some strange behaviour when creating application windows for a OI_add_timeout callback. Maybe someone out there has come across the same problem and/or knows a solution. I have extracted out two small text cases which exhibit the problem. They appear at the end of this note. What I am expecting to happen in the first test case is for an application window to be created and displayed every 5 seconds. On a Sparc Station IPX this is pretty much what happens, but as more and more windows are created, the rate at which windows are created increases, ie the timeout is being ignored. Things get pretty manic on a Sparc Station 20, my screen is rapidly filled with windows as though the callback is being called with no timeout whatsoever. If rather than creating a new window in the callback, I add a new static text item, everything works as expected. This is shown in the second test case. (OI 4.0 under Solaris 2.3) --- TEST CASE ONE --- /* This application creates and displays an empty application window once the application has been idle for 5 seconds. This process of adding application windows should continue ad infinitum approximatly every 5 seconds. */ #include void timeoutCB(void *argp) { OI_app_window * wind = oi_create_app_window( "wind",1,1,"wind"); wind->set_associated_object(wind->root(),OI_def_loc,OI_def_loc,OI_active); } void main( int argc, char **argv ) { OI_init( &argc, argv, "OI Timeout Test" ); OI_add_timeout(5000,timeoutCB); OI_begin_interaction(); OI_fini(); } --- TEST CASE TWO --- /* This application creates and displays an empty application window. Once the application has been idle for 5 seconds, a static text item is created and added to the window. This process of adding text continues ad infinitum approximatly every 5 seconds. */ #include #include OI_app_window *wind; void timeoutCB(void *argp) { static int index = 0; OI_static_text *text = oi_create_static_text("text","fred"); text->layout_associated_object(wind,1,index++,OI_active); } void main( int argc, char **argv ) { OI_init( &argc, argv, "OI Timeout Test" ); wind = oi_create_app_window( "wind",1,1,"wind"); wind->set_associated_object(wind->root(),OI_def_loc,OI_def_loc, OI_active); wind->set_layout(OI_layout_row_aligned); OI_add_timeout(5000,timeoutCB); OI_begin_interaction(); OI_fini(); } End of Message From owner-oi-users Mon Feb 20 07:31:10 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA24234 for oi-users-outgoing; Mon, 20 Feb 1995 07:31:10 -0800 Received: from marvin.boulder.openware.com (marvin.boulder.openware.com [192.245.99.138]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id HAA24222 for ; Mon, 20 Feb 1995 07:31:03 -0800 Received: from garya.boulder.openware.com (garya.boulder.openware.com [198.135.223.34]) by marvin.boulder.openware.com (8.6.9/8.6.9) with ESMTP id IAA18854; Mon, 20 Feb 1995 08:28:53 -0700 Received: (from garya@localhost) by garya.boulder.openware.com (8.6.9/8.6.9) id IAA20073; Mon, 20 Feb 1995 08:10:23 -0700 Date: Mon, 20 Feb 1995 08:10:23 -0700 From: Gary Aitken Message-Id: <199502201510.IAA20073@garya.boulder.openware.com> To: PWILLIAM%ESOC.BITNET@vm.gmd.de, OI-USERS@freefall.cdrom.com Subject: Re: Creating Application Windows in an OI_add_timeout callback Sender: oi-users-owner@FreeBSD.org Precedence: bulk > We are currently experiencing some strange behaviour when creating application > windows for a OI_add_timeout callback. Maybe someone out there has come across > the same problem and/or knows a solution. > > I have extracted out two small text cases which exhibit the problem. They > appear at the end of this note. > > What I am expecting to happen in the first test case is for an application > window to be created and displayed every 5 seconds. > > On a Sparc Station IPX this is pretty much what happens, but as more and more > windows are created, the rate at which windows are created increases, ie the > timeout is being ignored. > > Things get pretty manic on a Sparc Station 20, my screen is rapidly filled > with windows as though the callback is being called with no timeout whatsoever. > > If rather than creating a new window in the callback, I add a new static text > item, everything works as expected. This is shown in the second test case. The problem you are seeing is an X server performance problem; it degrades as the number of windows at the same place in the hierarchy increases. Once upon a time we verified this by doing a loop similar to yours (not in a timeout) and just doing XCreateWindow calls. From owner-oi-users Mon Feb 20 10:26:07 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA29909 for oi-users-outgoing; Mon, 20 Feb 1995 10:26:07 -0800 Received: from marvin.boulder.openware.com (marvin.boulder.openware.com [192.245.99.138]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA29903 for ; Mon, 20 Feb 1995 10:26:03 -0800 Received: from boulder.openware.com (localhost.boulder.parcplace.com [127.0.0.1]) by marvin.boulder.openware.com (8.6.9/8.6.9) with ESMTP id LAA22080; Mon, 20 Feb 1995 11:21:49 -0700 Message-Id: <199502201821.LAA22080@marvin.boulder.openware.com> To: Peter Williams Subject: Re: Creating Application Windows in an OI_add_timeout callback Cc: OI-USERS@freefall.cdrom.com In-reply-to: Your message of Mon, 20 Feb 1995 14:32:03 +0700 Date: Mon, 20 Feb 1995 11:21:46 MST From: Warner Losh Sender: oi-users-owner@FreeBSD.org Precedence: bulk : On a Sparc Station IPX this is pretty much what happens, but as more and more : windows are created, the rate at which windows are created increases, ie the : timeout is being ignored. : : Things get pretty manic on a Sparc Station 20, my screen is rapidly filled : with windows as though the callback is being called with no timeout whatsoever. : : If rather than creating a new window in the callback, I add a new static text : item, everything works as expected. This is shown in the second test case. I think that you have found a bug that another user on OI-users ran into. The simple workaround is to delete and add the callback inside timeoutCB. The set_associated_object winds up waiting for the window to become visible, which invilvles calling OI's main loop. The timeout callbacks aren't protected for this case, due to an oversite on my part, so the timeout fires right away. The problem is more pronounced on wall timeouts, but has the potential for affecting idle timeouts as well. Warner From owner-oi-users Wed Feb 22 08:26:50 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA21089 for oi-users-outgoing; Wed, 22 Feb 1995 08:26:50 -0800 Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.128.4]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA21083 for ; Wed, 22 Feb 1995 08:26:49 -0800 Received: from tenaya.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA15026 (5.65c/IDA-1.4.4nsd for ); Wed, 22 Feb 1995 08:26:24 -0800 Received: from localhost.NSD.3Com.COM by tenaya.NSD.3Com.COM with SMTP id AA04714 (5.65c/IDA-1.4.4-910730 for ); Wed, 22 Feb 1995 08:25:14 -0800 Message-Id: <199502221625.AA04714@tenaya.NSD.3Com.COM> To: oi-users@freefall.cdrom.com Subject: vanishing dialog box Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-6204 (Office) (408) 764-5000 (General Office) Date: Wed, 22 Feb 1995 08:25:13 -0800 From: priag Sender: oi-users-owner@FreeBSD.org Precedence: bulk Hi - We have an application which uses an object subclassed from OI_dialog_box to display results of a long-running operation. If the user closes the dialog box while the operation is running, I need to terminate that operation since there's no longer any place to display the output. If the user selects the abort button on the dialog box, everything works fine: I clean up and close the window. If the user dismisses the window from the window decoration, however, I can't get the behavior I want. Since the operation may run for quite a while, I would like to be able to prompt the user and dismiss the window/cancel the operation ONLY if the user confirms. In fact, my unpin callback gets called, but even if I return without taking down the window, OI makes it disappear after I return (apparently setting state to OI_not_displayed - it's not destroyed, just not visible). Is there any way to prevent this? I tried adding a terminate call back but it doesn't get called unless a button is selected. Any other ideas? Thanks, Pria Graves From owner-oi-users Wed Feb 22 09:52:08 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA23804 for oi-users-outgoing; Wed, 22 Feb 1995 09:52:08 -0800 Received: from lim.com (limbbs.lim.com [199.33.241.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA23798 for ; Wed, 22 Feb 1995 09:52:04 -0800 Received: from limbgb.lim.com by lim.com (8.6.9/3.1.020695 LIM, Int) via SMTP; id LAA01315 for ; Wed, 22 Feb 1995 11:51:20 -0600 Received: by limbgb.lim.com (4.1/1.1.020695) id AA01197; Wed, 22 Feb 95 11:51:29 CST Date: Wed, 22 Feb 95 11:51:29 CST From: brian@lim.com (Brian G. Benton) Message-Id: <9502221751.AA01197@limbgb.lim.com> To: priag@nsd.3com.com Subject: Re: vanishing dialog box Cc: oi-users@freefall.cdrom.com, brian@lim.com Sender: oi-users-owner@FreeBSD.org Precedence: bulk > From owner-oi-users@freefall.cdrom.com Wed Feb 22 11:06:17 1995 > To: oi-users@freefall.cdrom.com > Subject: vanishing dialog box > Phone.......: (408) 764-6204 (Office) > (408) 764-5000 (General Office) > Date: Wed, 22 Feb 1995 08:25:13 -0800 > From: priag > > Hi - > > We have an application which uses an object subclassed from > OI_dialog_box to display results of a long-running operation. If the > user closes the dialog box while the operation is running, I need > to terminate that operation since there's no longer any place to > display the output. > > If the user selects the abort button on the dialog box, > everything works fine: I clean up and close the window. > > If the user dismisses the window from the window decoration, however, > I can't get the behavior I want. Since the operation may run for > quite a while, I would like to be able to prompt the user and > dismiss the window/cancel the operation ONLY if the user confirms. > In fact, my unpin callback gets called, but even if I return without > taking down the window, OI makes it disappear after I return > (apparently setting state to OI_not_displayed - it's not destroyed, > just not visible). > I am assuming that you are using a Modal Dialog in this case. I had what I think is a similar problem with multiple modal dialogs. Ex. Modal Dialog A is active. The user selects a button in A that spawns a new Modal Dialog B. B is now the active Dialog as the user can no longer interact with A. However, the user can still select the close entry from the window manager menu on Dialog A. The following occurs when this happens: 1) My UnpinCB for Dialog A gets called 2) Modal Dialogs A&B are dismissed from the screen 3) The wait_button event loop of Dialog B is exited 4) Since a button in the button menu of Dialog B was never selected, the Validation callback for B is never called 5) The callback in Dialog A (which spawned Dialog B) completes 6) The Validation callback for Dialog A is called At this point (inside the Validation callback of A), we don't want to send back a FALSE value if the Dialog is not visible (OI changed the state of Dialog A & B to OI_not_displayed or OI_active_not_displayed, depending on how it is parented). If we did, we would stay in the wait_button loop of Dialog A with no Dialog in which to interact. Hence, we need to send back a value of TRUE in this case. Thus, I think if you provide a Validation callback testing for the above, it might solve your problem. It solved mine. Here is what I did: if ((ValidContents() == OI_YES) ((state() == OI_not_displayed) !! (state() == OI_active_not_displayed))) return 1; ValidContents() is merely a member function in my base Dialog class (which is subclassed from OI_dialog). It allows me to check the state of the ValidContents instance variable which I set depending on the validity of the Dialog contents. Subclassed from Dialog, I have ModalDialog and ModelessDialog (which are also abstract classes). Obviously your code would be slightly different, because you want to react differently, but the information you need is here. I assume you would want to post a Confirmation Dialog if the user dismisses via the window manager menu. In your case, you might want to make the Dialog visible once again after it's state has been changed by OI. But you will be able to tell if the Dialog has been brought down via the window manager menu and can act accordingly. Unfortunately, there is no way to catch the window manager selection in Dialogs as you can with OI_app_windows. That would solve this whole mess by allowing you to react before the Dialog disappears. I have been told by Openware that it can't be done. :-( > Is there any way to prevent this? I tried adding a terminate call > back but it doesn't get called unless a button is selected. Any other > ideas? Ooops. My case assumes that a button is selected from the button menu at the bottom of the Dialog, which was true for Dialog A in my example. This is why the Validation callback for A is obviously called. Why not make the select() method call on one of your menu cells in the Dialog menu? This should be the same as the user selecting the cell. Ex. Have a Cancel button (menu cell) which does exactly the same thing as the 'close' entry on the window manager. When your unpin callback is called, select the Cancel button programatically. This will cause your Validation (terminate) callback to get called after OI changes the state of the Dialog. It's a hack, but worth a try. > > Thanks, > > Pria Graves > +----------------------------------------------------------------------------+ | Brian Benton | Phone: (512) 346-5464 x21 | | Sr. MTS | Fax: (512) 346-5386 | | LIM International | Email: brian@lim.com | | 9390 Research Blvd., Kaleido II, #300 |------------------------------------| | Austin, TX 78759 | GO BRONCOS! GEAUX CAJUNS! | +----------------------------------------------------------------------------+ From owner-oi-users Wed Feb 22 11:09:31 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA25630 for oi-users-outgoing; Wed, 22 Feb 1995 11:09:31 -0800 Received: from lim.com (limbbs.lim.com [199.33.241.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA25624 for ; Wed, 22 Feb 1995 11:09:24 -0800 Received: from limbgb.lim.com by lim.com (8.6.9/3.1.020695 LIM, Int) via SMTP; id NAA01458 for ; Wed, 22 Feb 1995 13:08:41 -0600 Received: by limbgb.lim.com (4.1/1.1.020695) id AA01220; Wed, 22 Feb 95 13:08:52 CST Date: Wed, 22 Feb 95 13:08:52 CST From: brian@lim.com (Brian G. Benton) Message-Id: <9502221908.AA01220@limbgb.lim.com> To: oi-users@freefall.cdrom.com Subject: Problems with unparent() and layout_associated_object() Cc: brian@lim.com Sender: oi-users-owner@FreeBSD.org Precedence: bulk I have some questions concerning unparent(), layout_associated_object(), and Modal Dialogs. Thanks. My hierarchy: OI_dialog -> Dialog -> ModalDialog -> AttributeDialog (the dialog object below) -> ModelessDialog The problem exhibited is the following. I have a modal dialog contains two OI_box objects. These OI_box objects are retrieved via the call GetOIIndicatorsSubwindow() and GetOISecuritiesSubwindow(). Only one of these OI_box objects is visible at any given time. I have an exclusive check menu (retrieved via GetOISymbolTypeMenu()) that allows the user to choose which OI_box is currently visible. When the "Securities" menu cell is selected, the SecuritiesCB() callback member function is called and proceeds to unparent() the GetOIIndicatorsSubwindow() OI_box while calling layout_associated_object() on the GetOISecuritiesSubwindow() OI_box. When the "Indicators & Misc." cell is selected, the opposite occurs. This AttributeDialog object is created by an owner class and is invoked by calling PopupDialog(). PopupDialog() is a virtual member function defined in both ModalDialog and ModelessDialog. The ModalDialog version calls wait_button() while the Modeless version calls popup(). Since AttributeDialog is a modal dialog, wait_button() is called to invoke the dialog. Everything works ok after the first call to wait_button(). The two OI_boxes can be unparented and re-installed (layout_associated_object()) successfully. The problem arises after the dialog is brought down and an OI_box has been reassigned to the orphanage. If the dialog is brought back up again and one of the OI_box objects was unparented in the previous invocation and LEFT THAT WAY WHEN THE DIALOG WAS BROUGHT DOWN, the child objects of that OI_box are inactive (but visible) once that OI_box is re-installed in the latest invocation of the dialog. I attempted to solve this problem by writing the LayoutObject() member function below. It not only calls layout_associated_object() but also sets the state for each child object. Thus I can then interact with my child objects. It works for child objects of the OI_box. But my scroll_menu still has its menu cells inactive because they are not children of the OI_box. I could rewrite this method to account for all descendants, but we are getting to be real innefficient as my scroll list has a plethora of menu cells. There must be a better way. As a side note, dies anyone know why the destructor for OI_menu declared as non virtual protected? I have some OI_menu objects (OI_scroll_menu, OI_excl_check_menu, etc.) that I had declared as OI_menu objects in order to be generic as possible. However, when I go to delete this objects in the destructor, I don't have access to the destructor. Hence, I must declare them as OI_scroll_menu objects. I suspect that delete_all() might do the trick, but it seems like you should be able to use the C++ delete operator. I need to delete the objects in my destructor because I don't want the objects to be declared as internal objects (where OI will automatically delete them). The allow_internal_object() call causes adverse effects on the objects for which it is called. Ex. I override the set_state() method in OI_d_tech so that it sets the state not only on the object for which it is called, but for its child objects as well. If allow_internal_object() is called on a particular child object, the set_state() method will not get called on that object. Hence, I don't use allow_internal_object() (another OI bug). Also, if I use the C++ operator delete() on an OI object (ex. scroll menu), will its menu cells get deleted? If I call the C++ operator delete() on an OI_box, will its children get deleted? Or do they have to be set as internal objects? The following are snippets of code concerning the unparent() and layout_associated_object() problems. // This callback installs the Indicators OI_box and uninstalls // the Securities OI_box. void AttributeDialog::IndicatorsCB(OI_menu_cell *cell, void *, OI_number) { if (!cell->selected()) return; if (!GetOIIndicatorsSubwindow()) { GetParent()->set_working(); SetOIIndicatorsSubwindow(CreateOIIndicatorsSubwindow("indicators_subwindow")); GetParent()->clear_working(); } freeze(); // Make sure that the ColumnsSubwindow is not visible since it makes // no sense in this context. if (GetOIColumnsSubwindow()) GetOIColumnsSubwindow()->unparent(); // Unparent SecuritiesSubwindow if it exists if (GetOISecuritiesSubwindow()) GetOISecuritiesSubwindow()->unparent(); if (!GetOIIndicatorsSubwindow()->is_laid_out_child()) LayoutObject(GetOIIndicatorsSubwindow(), 20, 60, OI_active); /* GetOIIndicatorsSubwindow()->layout_associated_object(this, (OI_number) 20, // Column (OI_number) 60, // Row OI_active); */ unfreeze(); } /* IndicatorsCB() */ void AttributeDialog::LayoutObject(OI_d_tech *object, OI_number column, OI_number row, OI_state state) { OI_d_tech *child = NULL; object->layout_associated_object(this, column, row, state); while(child = object->next_child(child)) child->set_state(state); } /* LayoutObject() */ // This callback installs the Securities OI_box and uninstalls // the Indicators OI_box. void AttributeDialog::SecuritiesCB(OI_menu_cell *cell, void *, OI_number) { if (!cell->selected()) return; freeze(); // Make sure that the ColumnsSubwindow is not visible. It will become visible // once again when a security is selected. if (GetOIColumnsSubwindow()) GetOIColumnsSubwindow()->unparent(); // Unparent IndicatorsSubwindow if it exists if (GetOIIndicatorsSubwindow()) GetOIIndicatorsSubwindow()->unparent(); if (!GetOISecuritiesSubwindow()->is_laid_out_child()) LayoutObject(GetOISecuritiesSubwindow(), 20, 60, OI_active); /* GetOISecuritiesSubwindow()->layout_associated_object(this, (OI_number) 20, // Column (OI_number) 60, // Row OI_active); */ unfreeze(); } /* SecuritiesCB() */ Thanks, +----------------------------------------------------------------------------+ | Brian Benton | Phone: (512) 346-5464 x21 | | Sr. MTS | Fax: (512) 346-5386 | | LIM International | Email: brian@lim.com | | 9390 Research Blvd., Kaleido II, #300 |------------------------------------| | Austin, TX 78759 | GO BRONCOS! GEAUX CAJUNS! | +----------------------------------------------------------------------------+ From owner-oi-users Fri Feb 24 08:10:23 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA19136 for oi-users-outgoing; Fri, 24 Feb 1995 08:10:23 -0800 Received: from Sun.COM (Sun.COM [192.9.9.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA19127 for ; Fri, 24 Feb 1995 08:10:19 -0800 Received: from EBay.Sun.COM (female.EBay.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09684; Fri, 24 Feb 95 08:09:09 PST Received: from odessa.EBay.Sun.COM by EBay.Sun.COM (SMI-8.6.9/SMI-5.3) id IAA18493; Fri, 24 Feb 1995 08:09:07 -0800 Received: by odessa.EBay.Sun.COM (5.0/SMI-SVR4) id AA26234; Fri, 24 Feb 1995 08:10:46 +0800 Date: Fri, 24 Feb 1995 08:10:45 -0800 (PST) From: Tony Gaw To: oi-users@freefall.cdrom.com Subject: resend: glyph click callback/drag object (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: oi-users-owner@FreeBSD.org Precedence: bulk (sorry if you saw this already) I have a OI_glyph object which has a click callback from gp->set_click(). It worked fine until I made this OI_glyph draggable by overriding the OI_glyph translation: static char button_trans[] = ": drag_copy_start()\n"; Because of the above trans, my glyph click callback never gets called. Any tips on how to get both the click callback AND draggability to work on my glyph? BTW, I'm trying to mimic Sun's filemgr icons - which allow the icon to be selected (one click), viewed (double click), and dragged. TIA.