Would threading be any use here?

  • Thread starter Thread starter Keith
  • Start date Start date
K

Keith

I'm writing an application that is somewhat similar to Visual Studios
GUI Designer.

Now my problem lies in that sometimes when there is a large number of
forms read in from file, that there seems to be a serious lag in
painting the controls. This doesn't always happen, but once the lag
happens it won't happen again when the file is loaded. It seems to be
some delay in loading the controls.

Now most of the controls are .NET drawn (although a few are owner
drawn).

The application uses a treeview to show all the different controls,
dialogs, etc. The code to show the controls is done in the AfterExpand
( ) and AfterSelect ( ) event functions. Now there is a fair bit of
code in these functions, but there doesn't seem to be any other way to
cut them down, and make them more efficent.

I have been thinking about perhaps threading the UI code that appears
in these function as it seems to cause a bit of lag. However I'm
making absolutely no progress at all, does anyone have any ideas on how
to progress? It's really starting to do my head in.

Thanks in advance,
Keith
 
Where is the time... changing the UI, or fetching the data required to
change the UI?

If the latter, then yes: this would be a good scenario for threading; you
would typically change the UI element to a "loading..." state (if you see
what I mean), and then kick of a worker (either async callback or
threadpool) to fetch the data (some kind of data structure, e.g. array of
required object contents; NOT ui elements); then when obtained, call back to
the UI thread (.BeginInvoke) and ask the UI to update itself.

Lots of examples on google. You would, however, need to think about thread
safety and concurrent actions...

Marc
 
I would echo what the other poster has said : you really need to know where
the time is going.

For that I recommend using a profiling tool such as ANTS profiler.

Until you know where the time is being spent you're just shooting in the
dark.

Regards,

Adam.
========
 
Adam said:
I would echo what the other poster has said : you really need to know where
the time is going.
Click to expand...

Another echo. Yes, you've got to find out what it taking the time.

Many years ago I spent ages trying to speed up an application that was
doing a lot of intensive file operations, setting up all sorts of
buffering systems. When I finally ran a profiler on the program it
turned out that almost all the time was being taken up by the progress
bar on the screen. It's the sort of lesson you only need to learn once!
 
Back
Top