On Mar 30, 6:46*pm, Jake Colman wrote:
> I have some logic that creates a large number of screens. *Each screen
> causes data to be fetched from the database. As a result, the screens
> get half-painted as the system load climbs. *Is there a way to create
> the screens but prevent anythung from being rendered until all the work
> is completed. *Maybe I would put up one screen that saus "We are very
> busy" and all the other screen painting won;t happen until all the setup
> work is completed. *I would expect that would reduce the load since the
> server won't need to paint and everything would execute must more
> quickly.
>
> Am I making any sense?

When you say you create "screens", this makes me think you are not
using Motif, but rather some Microsoft windows app. This newsgroup is
for discussing Motif applications on Unix/Linux platforms.


If indeed you are using Motif and you mean you create several dialogs,
just unmanage the shell widget until you are finished filling it, then
manage the shell.

--
Fred Kleinschmidt

>>>>> "flk" == fred l kleinschmidt writes:

flk> On Mar 30, 6:46*pm, Jake Colman wrote:

>> I have some logic that creates a large number of screens. *Each
>> screen causes data to be fetched from the database. As a result,
>> the screens get half-painted as the system load climbs. *Is there
>> a way to create the screens but prevent anythung from being
>> rendered until all the work is completed. *Maybe I would put up
>> one screen that saus "We are very busy" and all the other screen
>> painting won;t happen until all the setup work is completed. *I
>> would expect that would reduce the load since the server won't
>> need to paint and everything would execute must more quickly.
>>
>> Am I making any sense?

flk> When you say you create "screens", this makes me think you are
flk> not using Motif, but rather some Microsoft windows app. This
flk> newsgroup is for discussing Motif applications on Unix/Linux
flk> platforms.

flk> If indeed you are using Motif and you mean you create several
flk> dialogs, just unmanage the shell widget until you are finished
flk> filling it, then manage the shell.

Hi, Fred. Yes, I am definitely using Motif. We are creating top-level
shells and fetching the widgets from a UIL file. Within a loop, I am
creating a shell and feteching data from a database to populate the
various widgets within a shell. I have a progress dialogue that
displays progress as we do the work. If I test this logic with an
increasing number of iterations, everything slows down. In other words,
opening 20 windows takes more than twice the time as 10 windows.

What do you suggest for this? Are shells automatically managed when
created? Or automaically mapped? Would changing this behavior making
things faster?

--
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA 19428
+1 (610) 755-9786
www.principiapartners.com

--
Posted via a free Usenet account from http://www.teranews.com

On Apr 1, 10:23*am, Jake Colman wrote:
> >>>>> "flk" == fred l kleinschmidt writes:
>
> * *flk> On Mar 30, 6:46*pm, Jake Colman wrote:
>
> * *>> I have some logic that creates a large number of screens. *Each
> * *>> screen causes data to be fetched from the database. As a result,
> * *>> the screens get half-painted as the system load climbs. *Is there
> * *>> a way to create the screens but prevent anythung from being
> * *>> rendered until all the work is completed. *Maybe I would put up
> * *>> one screen that saus "We are very busy" and all the other screen
> * *>> painting won;t happen until all the setup work is completed. *I
> * *>> would expect that would reduce the load since the server won't
> * *>> need to paint and everything would execute must more quickly.
> * *>>
> * *>> Am I making any sense?
>
> * *flk> When you say you create "screens", this makes me think you are
> * *flk> not using Motif, but rather some Microsoft windows app. This
> * *flk> newsgroup is for discussing Motif applications on Unix/Linux
> * *flk> platforms.
>
> * *flk> If indeed you are using Motif and you mean you create several
> * *flk> dialogs, just unmanage the shell widget until you are finished
> * *flk> filling it, then manage the shell.
>
> Hi, Fred. *Yes, I am definitely using Motif. *We are creating top-level
> shells and fetching the widgets from a UIL file. *Within a loop, I am
> creating a shell and feteching data from a database to populate the
> various widgets within a shell. *I have a progress dialogue that
> displays progress as we do the work. *If I test this logic with an
> increasing number of iterations, everything slows down. *In other words,
> opening 20 windows takes more than twice the time as 10 windows.
>
> What do you suggest for this? *Are shells automatically managed when
> created? *Or automaically mapped? *Would changing this behavior making
> things faster?

The top widget in the UIL tree (4th parameter of MrmFetchWidget) is
initially
unmanaged. Be sure you are doing things in this order:

status = MrmFetchWidget( ..., &my_widget, ... );

/* do other thijngs here to set dynamic contents of widgets in
* the tree with my_widget at the top
*/

XtManageChild( my_widget );

In other words, be sure to manage the widget AFTER you fill in
the other information.
--
Fred Kleinschmidt

>>>>> "flk" == fred l kleinschmidt writes:

flk> On Apr 1, 10:23*am, Jake Colman wrote:
>> >>>>> "flk" == fred l kleinschmidt
>> >>>>> writes:
>>
>> * *flk> On Mar 30, 6:46*pm, Jake Colman wrote:
>>
>> * *>> I have some logic that creates a large number of
>> screens. *Each * *>> screen causes data to be fetched from the
>> database. As a result, * *>> the screens get half-painted as the
>> system load climbs. *Is there * *>> a way to create the screens
>> but prevent anythung from being * *>> rendered until all the work
>> is completed. *Maybe I would put up * *>> one screen that saus "We
>> are very busy" and all the other screen * *>> painting won;t
>> happen until all the setup work is completed. *I * *>> would
>> expect that would reduce the load since the server won't * *>>
>> need to paint and everything would execute must more quickly. *
>> *>> * *>> Am I making any sense?
>>
>> * *flk> When you say you create "screens", this makes me think you
>> are * *flk> not using Motif, but rather some Microsoft windows
>> app. This * *flk> newsgroup is for discussing Motif applications
>> on Unix/Linux * *flk> platforms.
>>
>> * *flk> If indeed you are using Motif and you mean you create
>> several * *flk> dialogs, just unmanage the shell widget until you
>> are finished * *flk> filling it, then manage the shell.
>>
>> Hi, Fred. *Yes, I am definitely using Motif. *We are creating
>> top-level shells and fetching the widgets from a UIL file. *Within
>> a loop, I am creating a shell and feteching data from a database
>> to populate the various widgets within a shell. *I have a progress
>> dialogue that displays progress as we do the work. *If I test this
>> logic with an increasing number of iterations, everything slows
>> down. *In other words, opening 20 windows takes more than twice
>> the time as 10 windows.
>>
>> What do you suggest for this? *Are shells automatically managed
>> when created? *Or automaically mapped? *Would changing this
>> behavior making things faster?

flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
flk> is initially unmanaged. Be sure you are doing things in this
flk> order:

flk> status = MrmFetchWidget( ..., &my_widget, ... );

flk> /* do other thijngs here to set dynamic contents of widgets in
flk> * the tree with my_widget at the top
flk> */

flk> XtManageChild( my_widget );

flk> In other words, be sure to manage the widget AFTER you fill in
flk> the other information.
flk> --
flk> Fred Kleinschmidt


So if I have text fields that display values based on the record of data
being loaded into the window or option lists that get initiaized to a
specific value based on that record, I call XtManageChild() only after
all data loading is complete and I have specified the value for each
widget?


--
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA 19428
+1 (610) 755-9786
www.principiapartners.com

--
Posted via a free Usenet account from http://www.teranews.com

>>>>> "Jake" == Jake Colman writes:

>>>>> "flk" == fred l kleinschmidt writes:
flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
flk> is initially unmanaged. Be sure you are doing things in this
flk> order:

flk> status = MrmFetchWidget( ..., &my_widget, ... );

flk> /* do other thijngs here to set dynamic contents of widgets in
flk> * the tree with my_widget at the top
flk> */

flk> XtManageChild( my_widget );

flk> In other words, be sure to manage the widget AFTER you fill in
flk> the other information.
flk> --
flk> Fred Kleinschmidt

Jake> So if I have text fields that display values based on the
Jake> record of data being loaded into the window or option lists
Jake> that get initiaized to a specific value based on that record, I
Jake> call XtManageChild() only after all data loading is complete
Jake> and I have specified the value for each widget?

I apologize for following up my own post.

How does XtManageChild() relate to whether the screen is or is not
displayed, that is, viewable to the user. If the screen is not visible,
would I still have a performance hit if I have called XtManageChild()
before I am done initializing all the data in the widgets?

--
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA 19428
+1 (610) 755-9786
www.principiapartners.com

--
Posted via a free Usenet account from http://www.teranews.com

On Apr 1, 8:49*pm, Jake Colman wrote:
> >>>>> "Jake" == Jake Colman writes:
> >>>>> "flk" == fred l kleinschmidt writes:
>
> * *flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
> * *flk> is initially unmanaged. Be sure you are doing things in this
> * *flk> order:
>
> * *flk> status = MrmFetchWidget( ..., &my_widget, ... );
>
> * *flk> /* do other thijngs here to set dynamic contents of widgets in
> * *flk> * the tree with my_widget at the top
> * *flk> */
>
> * *flk> XtManageChild( my_widget );
>
> * *flk> In other words, be sure to manage the widget AFTER you fill in
> * *flk> the other information.
> * *flk> --
> * *flk> Fred Kleinschmidt
>
> * *Jake> So if I have text fields that display values based on the
> * *Jake> record of data being loaded into the window or option lists
> * *Jake> that get initiaized to a specific value based on that record,I
> * *Jake> call XtManageChild() only after all data loading is complete
> * *Jake> and I have specified the value for each widget?
>
> I apologize for following up my own post.
>
> How does XtManageChild() relate to whether the screen is or is not
> displayed, that is, viewable to the user. *If the screen is not visible,
> would I still have a performance hit if I have called XtManageChild()
> before I am done initializing all the data in the widgets?
>

When you retrieve the widget tree with MrmFetchWidget, nothing is
visible until you call XtManageChild on the retrieved top widget.

You may or may nbot get a performance hit by managing the widget
before filling in all the data. The main thjing that would cause
performance hits is if internal sizing depends on the contents of the
widgets (if text fields are not fixed size, but grow or shrink based
on the contents), if there are lists (fill all items in the list
before it
is managed; otherwise it redraws every time a new item is added), etc.

--
Fred Kleinschmdit