I have a large number (200+) of various types of widgets that I am displaying on 30 tab pages in a notebook. Every widget is displayed on every tab page. Is there a way that I can create just one set of these widgets and reuse them (repopulate them) when the user changes tab pages? Can I reparent these widgets?
Thank you.
Tue, 07/24/2012 - 12:04
#1
Reusing Large Number of Widgets
Reparenting isn`t an option. It is done once within Motif, as a special case for tear-off menus. Perhaps there are light-weight versions of the objects that you can use instead, or perhaps the page can exist once and be repopulated with data according to what the user is doing (without recreating the widgets).
The key is to not make the parent of the widgets the tab / notebook pages. What I did was place the Notebook and create pages and then place the other items on a form and make its parent the same parent as the Notebook. Then as the pages are changed I repopulate the widgets with the data that should be associated with the tab.
Here is a rough example of the code...
//Create Parent form...
Parent = XmCreateForm(...
//Create Notebook...
Notebook = XmCreateNotebook(Parent, ...
XtManageChild(Notebook);
//Create and manage pages...
//NOTE Use the Notebook for the Parent of the Pages >)
for(i = 0; i < NumOfPages; i++)
{
Pages[i] = ...
XtManageChild(Page[i]);
}
//Manage the Parent
XtManageChild(Parent);
/*Then create the additional widgets and manage them. I would place them all on a form, and using the Parent (above) as the Parent of the Form, because you will have to do a little work to position the Form the way that you want it so that it is floating above the Notebook and appears to be a part of it. You will probably need to use offsets (XmNtopOffset, XmNbottomOffset, XmNleftOffset, XmNrightOffset) to position it so that it looks centered on the Notebook pages when they are changed.
Let me know if you have any problems with this. It took me a while, but it`s nice once I got it working. A lot less to keep track of and saves resources. >)
Good Luck...
C. Lamb
Note Once problem that arises is when attempts are made to add pages to the Notebook, etc... Initially when the floating form is positioned over the Notebook the appearance is as desired; however, since the positioning is controlled by the developer (code writer) the floating form is stationary. If a Page is added where the tab name is long I have experienced problems where the tabs are shifted under the floating form. So, code might (will >) ) need to be written to reposition the form in instances such as these; therefore, making the appearance better and the tabs visible to the user.
Hi,
Back to what dbl was "warning about". When you say re-use. Reuse how? Is it in some kind of container? Is it Xt or Xm widget. Does it inheirit properties?
My point is this. Visible widgets accumulate settings, like "highlighting" as the X engine moves along. Each widget becomes part of, well, a record of everything happening. They can retain settings in an interaction that are not easily "discovered" and in some cases irreversible.
So they could misbehave if you use them in a new way.
For example. If widget A is on page A (wA, pA). If the user has highlighted wA in Pa, should wA be highlighted in pB ? Or should each page of widgets contain its own information?
If its an Xm widget you need to see what properties it may inheirit. Many of these widgets can have nasty side effects when used with else but in the parent.
For example. Does each page call a layout function
that is not the parent`s layout function? Better
be carefull with that. What can settings can you
use with the parent you are choosing to re-layout
the same icons in a new way?
Also, X can cache certain "mundane" operations. What happens if an icon operation is cached, you switch tabs, then the "number" is called?
200 isn`t that bad. You can spin off 500 new widgets pretty quick. Anyway likely 500 widgets couldn`t be visible. And I think its best if you only create widgets that are in the display, not all widgets that *might* sometime be in the display.
My anecdodal evidence is that motif filemanager spin-offs have great difficulties with very large directories, for reasons I caching reasons won`t explain here. At any rate, the default "off view" cache function is only built to cache a few invisible icons (on a *large* X display with many objects).
A typical "Xm" widget in my view is a short-lived object that represents what the user can see and has done in the current view. To "save" objects, on should dump only certain info like selection, and reset those in a new widget if it ever becomes visible again. Other information in the widget may be very much tied to the view itself - which might change due to user action - some of which will cause crashes if changed, and the valid "change" is only to create a new widget.
X and Motif spin off widgets in this manner, (ie scrolling by removing old widgets from control and creating new ones coming into view), very quickly. And in this way, in a highly stable manner.
So... Be careful of where you get this widget from. Re-use only widgets that have class data (usually tied to code not in your code) you can account for completely.
If I were you I`d be worried about how *not* to create that many existing icons in one parent how to create widgets as needed from your app data. 3000 sounds like enough to "break" things if all put in one GC. If I remember GC`s have a limit (that can be checked if necessary).
Hope that helps,
John