Sorry for a bit strangely phrased subject line - I simply did not come
up with anything better. Smile.
OK, I have a couple of cases in my app, where some information has to be
gathered and processed, before it is all presented in a dialog. For
instance, I have one dialog, holding a treeview. The information that is
to be displayed is gathered from numerous files on the hard drive. this
"information harvesting" does only take a second or so on a fast SSD
drive. Another story is when you happen to run the app from things like
a notebook or if you are running the stuff on a computer that has high
amount of other traffic going on at the same time.
What happens, is that the treeview will come up, typically with
something like 3 or 4 root entries displayed right away. Within the next
3 or 4 seconds, I notice that the tree "grows", slowly but steadily, as
the files are being harvested and the individual entries for the tree is
being processed. This may be a bit confusing for the end-user. He right
away is told there is 5 entries, but if he checks the treeview in a few
seconds, there is 15 - which is actually the full tree at this point.
Well, my idea could of course have been to simply use some kind of sleep
command in opening the treeview, and let it all rest for say 5 seconds,
hoping that would give the tree time enough to get fully grown. But for
a user with a high-speed computer, 5 seconds of waiting with a blank
screen, would be rather frustrating. Hmm, wonder how we got along in the
80s when it took three minutes for the software to even load. Smiles.
My question is, if anyone has a tip for me, as to how I can have the
dialog come up, when the tree is fully grown, and not anything before. I
would much rather have a message given to the user to please wait, until
the full tree can be presented to him. I think that would make things
look a bit more professional, than to let him see the tree grow. Any ideas?
Another case, somehow down the same lane. I have installed the WESounds
app, which I find really helpful since it gives different sounds,
depending on what kind of screen you are in. Like, when you land on a
menu, you get this sound - when a dialog open, you get another one.
Thanks to GW for providing this app.
Anyway, I have a quite simple dialog in my app, that simply holds one
edit box, and one close-button. In other words, the dialog does not take
much time to neither open nor fill with information. In this case, all
the information is processed ahead of time, and the edit box will simply
just have a chunk of text passed onto it. BTW, it is a read-only edit box.
OK, so where is my issue here? Every now and then, I realize that the
dialog text is being spoken - either most of it, or sometimes even the
whole text - before the sound indicating that I have landed on a dialog
screen is heard. To what extent this is a delay in the WESound app, or
if it has to do with my dialog not being opened and fully filled in
quickly enough, I am not sure. It just puzzles me that the text will
start reading sometimes several seconds prior to that dialog sound
coming up.
Am I missing some kind of instruction in my dialog making and handling?
Or, are these known issues that someone has a good little workaround
for? I seem to have followed the custom of defining sub-routines for
opening the dialogs, calling these by queue commands, and then parsing
it all through a dialog event handler function - all in accordance with
what I can see from other apps' coding, and what has been described
quite well in Chip's Scripting classes (which I by the way have enjoyed
much). Again, thanks for any ideas, tricks and tips, that might lead me
on the track of a more smoothly working app.
--
David
- Waiting for a dialog to be completed David
-
