eelko
asked on
Smooth UI with messages to child windows
My problem is that when I send a message A to a child window of my SDI application previous event like opening menu will be executed after this message A is handled.
Let me explain a bit more.
My SDI application looks like the Windows explorer. Two views within the mainframe. The left view is a tree view, the right view displays information about the selected item in the left view. The amount of items in the tree view could be huge so I decided not to build the whole tree at initialisation but only build the childs of an item when the user asks to expand this item. But since some items have many childs it still takes a while before the user gets the control back.
I thought about a solution to send a message to the tree view which will build X items and then send the same message again. With the idea that between these messages the mainframe could handle other events before the next message is handled.
But this does not work :-(
I also thought about a second thread which does the building-tree-job. But I am not sure (yet) how this should work since the view is part of the UI.
Do you have any ideas or comments which lead to a solution for my problem?
Let me explain a bit more.
My SDI application looks like the Windows explorer. Two views within the mainframe. The left view is a tree view, the right view displays information about the selected item in the left view. The amount of items in the tree view could be huge so I decided not to build the whole tree at initialisation but only build the childs of an item when the user asks to expand this item. But since some items have many childs it still takes a while before the user gets the control back.
I thought about a solution to send a message to the tree view which will build X items and then send the same message again. With the idea that between these messages the mainframe could handle other events before the next message is handled.
But this does not work :-(
I also thought about a second thread which does the building-tree-job. But I am not sure (yet) how this should work since the view is part of the UI.
Do you have any ideas or comments which lead to a solution for my problem?
ASKER
Thanks for the comment,
I will read the second UI thread documentation first and then make a decision.
The array idea within the worker thread is a nice idea. I will give it my thoughts.
I will read the second UI thread documentation first and then make a decision.
The array idea within the worker thread is a nice idea. I will give it my thoughts.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You are probably using SendMessage. This function does not return until the message is handled, and does not go via the normal application message pump (it calls the window function directly).
PostMessage has a similar effect except that it doesn't call the window function directly; instead it puts the message in the message queue and returns immediately. The message will be handled later when the application message pump gets round to it.
(I am not saying this is the best way to do it as opposed to the methods mentioned by the other posters, but it is the direct answer to the question you asked.)
PostMessage has a similar effect except that it doesn't call the window function directly; instead it puts the message in the message queue and returns immediately. The message will be handled later when the application message pump gets round to it.
(I am not saying this is the best way to do it as opposed to the methods mentioned by the other posters, but it is the direct answer to the question you asked.)
When using PostMessage, you have additional problems - like making sure pointer parameters (strings, TVITEM * etc.) are still valid when the message is handled (so using a local TVITEM is a no-no)
ASKER
Yechezkel thanks for your comment but I already use PostMessage and not SendMessage.
Peterchen, you're right that a local TVITEM variable passed to a PostMessage will not work. So I already created my own object with all the necessary information. This object (a pointer to it) I pass with my PostMessage. The state of the object is allways valid, since I get the right data on the screen.
B.T.W. I am still studying the worker thread idea.
Peterchen, you're right that a local TVITEM variable passed to a PostMessage will not work. So I already created my own object with all the necessary information. This object (a pointer to it) I pass with my PostMessage. The state of the object is allways valid, since I get the right data on the screen.
B.T.W. I am still studying the worker thread idea.
did you try any of the Controls? As said, I have no experience, but esp. the WaitingtreeCtrl god very enthusiastic feedback
Well, just some comments about your own object...
First, you don't need to create your own object - you can just allocate the TVITEM on the heap and pass a pointer to it... (use malloc). This gives the advantage of not having to create your own object.
Second, are you remembering to free the object you are PostMessaging? You probably are, but memory leaks are afterall some of the harder problems to find... and this sounds like the perfect environment for a memory leak.
Third, I would suggest you use SendMessage. This way you avoid allocating memory for extra objects and such. There's no reason I can think of to post the message...
Anyways, good luck.
First, you don't need to create your own object - you can just allocate the TVITEM on the heap and pass a pointer to it... (use malloc). This gives the advantage of not having to create your own object.
Second, are you remembering to free the object you are PostMessaging? You probably are, but memory leaks are afterall some of the harder problems to find... and this sounds like the perfect environment for a memory leak.
Third, I would suggest you use SendMessage. This way you avoid allocating memory for extra objects and such. There's no reason I can think of to post the message...
Anyways, good luck.
ASKER
Peterchen, thanks for the links. These articles helps me a lot.
Cirus, although the idea of another thread sounds nice, it also gives a lot of code to implement and test.
Anyway, thanks for your comments and ideas.
Cirus, although the idea of another thread sounds nice, it also gives a lot of code to implement and test.
Anyway, thanks for your comments and ideas.
But really, I'd suggest you begin a worker thread, and have it build the items into an array, then send a message to the main UI thread with the array pointer once the building is complete. All the UI has to do is call AddItem on the tree ontrol then...
Yet another option would be to make a worker thread that would build only a few items, maybe 5 or 10, and send an array to the main UI thread of those items, and the UI thread updates the tree control then. In this way, for really long lists, it creates the effect that the UI is showing the items getting loaded - the scroll bar shrinks, the user can go and pick one while the tree control is being filled, whatever.
Getting back to the first thing, a second UI thread. You wouldn't have to create such a thread each time you wanted the update - it could be in charge of the tree control continually.
Anyways, does this seem to answer your problem?