Hi David! Good to hear from you again, and thanks for the kind words.
For #1 problem, the approach I like to do is to open the dialog right away (with controls empty), and in the portion which handles the dialog create event (of the dialog event handler), there I will start my process to collect data (using a queue command). I will often pass the dialog object to this process, so that it loads the treeview or whatever with the info it is gathering. Well, when you do things this way, you can add a progress bar to your dialog, and your info gathering process can keep the progress bar updated; or, for less programming, your gathering process can speak a "please wait" at the start; and at the end use a silence command, followed by a spoken message such as "ready" or "complete" or whatever to indicate things are ready. Sometimes I just use a little "ding" sound of some sort to indicate things are ready. If you don't have room on your dialog for a progress bar, the info gathering process can open its own dialog on top of yours to display the progress bar and nothing else, and this way the user isn't left in the treeview control as it is filling. When all the info has been gathered, you just close the progress bar dialog, and activate the dialog with your controls, and focus your treeview or main control. Unfortunately, for question #2, there just isn't anything you're doing incorrectly, and there isn't a way to synchronize your app's thread with the thread of the WE Sounds app (which can be a little behind if your system is busy). I depend on WE Sounds myself, and like it quite a bit, and you're right; sometimes it lags quite a bit and I don't know why. I suppose you could grab some of its .wav files and play the sounds yourself in your app, making it an option? You could probably look an older copies of appGet source code to see how the progress bar is used while the info it gathers comes down from the internet. All versions of all apps are kept on App Central, and so with a little digging you could eventually dig up one of the earlier versions of appGet which weren't encrypted. If not appGet, then the UI Design app uses a progress bar while it does info gathering I believe, and it's not encrypted. Hth and good luck, Chip -----Original Message----- From: David [mailto:[email protected]] Sent: Thursday, December 18, 2014 2:32 PM To: [email protected] Subject: Waiting for a dialog to be completed 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
