OK David,
If you don't have a variable named DialogCreated, then this line is in error and is causing one of your problems. Actually, causing two of your problems as your line for when the dialog is closing may be executing every time as well. One of the events is indeed that the dialog is being created, but you have to test for it by seeing if the parameter to the event handling dialog is equal to the constant for this event. The line I pointed out in my original email isn't testing to see if this parameter equals the constant, you just have the name of the constant as the "if" condition. Since this constant is not 0, it will always evaluate in the "if" command as true (that's a trick of the "if" command which I don't like, but if you don't have a Boolean condition there, but instead you just have a number, it acts as if you have a Boolean condition; that is, if the number is not 0, it evaluates as if it was a Boolean true). You can see this in the Immed app by typing in a command such as: If 123 then speak "yes" (and you should hear "yes") And then try: If 0 then speak "something is wrong" (and you should not hear anything) So, you need to change the "if" where you are testing to see if the dialog is being created, and also where you are testing to see if it's being closed, to be conditions where you compare the event parameter against those constants. If the name of your parameter is dEvent, then they should look like: If dEvent = DialogClosing then ' and here should be the code for when it closes . If dEvent = DialogCreated then ' code here should be the code for when the dialog is being created . That way the code will only execute once, and will execute at the correct time. Please, if you find an example from a scripting class where I don't have an test with a Boolean condition like I just described, do let me know which class it is and I will correct the example. I have been correcting the examples as I find things like this, and Aaron has been good enough to repost them for me. Hth, Chip From: David [mailto:[email protected]] Sent: Wednesday, January 29, 2014 12:52 PM To: [email protected] Subject: Re: Treeview experience, some interesting observations OK, Chip, Just to clarify one point, at least. The Case Else section in my DialogHandler, was taken pretty straight forward, from what I see others do, and I even believe one of your Scripting Classes which dealt with the Dialog Handler function - Don't remember the number of the class. The only line I changed, was the one that calls the FillTree sub. Now, is the DialogCreated and DialogClosing events? Here is a cut from the GW app developers reference: The Window-Eyes Object Model >Enumerations >DialogEvent Specifies event types for Window-Eyes custom UI dialogs. Name Value Description dialogCreated 0x0110 The dialog was created dialogClosing 0x0010 The dialog is closing ... >From that, I don't see what I am missing, and hoped someone could tell me, if the coding is wrong in this section, or if the DialogCreated event fires every time you move from one control to the other, and if so, why. Even if the rest of the code samples I gave will not explain the other issues I had, I at least hope this will help tracing why my Treview gets refilled every move from one control in the Dialog, to another. Thanks for your feedback, ----- Original Message ----- From: Chip Orange <mailto:[email protected]> To: [email protected] Sent: Wednesday, January 29, 2014 3:44 PM Subject: RE: Treeview experience, some interesting observations Hi David, I'm afraid it's a little too hard to guess based on your descriptions; I think you'll have to post the code. One bit of code you did post had to do with the tree being expanded with 10 more items every time you tabbed away and back to it; you posted: If DialogCreated Then This looks like you're using a variable to track this which isn't getting reset; it's better to test on the event = dialogCreated rather than testing on a variable you have. Yes, I too have had problems which occur because I am doing something every time the dialog event handler is being called, even when it was being called because the dialog was closing (which caused me problems), so yes, you have to test on whether the event indicates the dialog is closing. Hth, Chip From: David [mailto:[email protected]] Sent: Wednesday, January 29, 2014 7:08 AM To: [email protected] Subject: Treeview experience, some interesting observations Listers, I have been playing around with the Treeview in a couple of my projects lately. And, I have been looking at a few Apps, to get the idea of how to handle the Treeview. Things basically are up running by now, but I have made a couple of interesting observations. I wonder if I am misunderstanding something, or if there is a whole in my knowledge. Likely some of you, have made similar experiences. First of all, I made a Dialog in the XML, holding a Treeview, and two buttons - like an OK, and a Cancel button. Things got more advanced later on, but for now, let's concentrate on this basic Dialog. Next, back to the code, and build a Queued sub, to call the Dialog Handler function of the Treeview Dialog. All that, worked just fine, and I got things to display on the screen. Now was the time, to start fill in the information in the Treeview. The info I needed, was all stored in a file on the computer, so to retrieve it, and have it correctly filled into the Tree, was quite easy. After all, the treeview I am working on in one project, only holds the Root, and some entries in the first Child level. To make all the filling of the tree easy as possible, I placed all of that processing stuff, in a sub, called "FillTree". I pass the Treeview object, as the parameter to the sub, from inside my Dialog Handler. Something like: FillTree DObj.Control( "MyTreeview") DialogHandler = True Exit Function Fine. The Treeview gets filled, with something like ten entries in the Root, and anything from one to ten entries in the first sublevel for each Root entry. All as expected. Yet, now comes my observations. Running the app, the Dialog opens, and you land on the Treeview. The FillTree routine has been called, so your screen will show a treeview, with ten entries in the Root. You now try to tab to the OK button, and then tab back to the Treeview. What do you think, other than now your treeview will hold twenty entries in the root. Perform the act ten times, and your entries will be tenfold in the root. OK, I see what is the case, everytime I land on the treeview, the FillTree sub is called, causing it to add on the same entries all over, thereby raising the number of entries. The stuff is basic enough this far. My question number one to all of you experienced ones, is: Where in the Dialog Handler should I perform the FillTree call? I thought, based on primitive thinking, that I could place it near the end of the Handler. There, I have a section like this: Case Else If DialogCreated Then FillTree DObj.Control( "MyTreeview") ElseIf DialogClosing Then BlahBlahBlah Since I reasoned this section would only be effective when the Dialog was all created, I thought this would be the place to fill in the Treeview. Yet, it seems for some strange reason, that I was wrong. My testing has revealed, that the stuff in the above samplified section, will be executed on each move I make in the Dialog, and thereby keep "filling things into the treeview", whenever I tab around. OK, I figured one solution, in that I let the FillTree sub, start out by a Clear command, to start with an empty treeview, and refilling it from scratch, everytime the call comes. But, that also lead to another issue, as now I will keep ending up at the top of the treeview, everytime I tab away, and back to the tree. I further figured, that I could store the selected Node, at any given time, and let the FillTree sub conclued every run, by focusing the stored selectedNode. That works just fine, long as I am in the Dialog operating. And, if I hit the Cancel button of the Dialog - which simply cause a DObj.Close call inside the Dialog Handler, the stuff may work in some cases. What happens, is that long as I am focusing the root of the treeview, then hitting the Cancel button, things close troublefree. But, when I have expanded one of the Root Nodes, and focused a Node on the first sublevel, then hit the Cancel button, the dialog close, and the screen reader crashes altogether. It actually crashes that much, you get this three-note tiny tune, and the computer hangs for several minutes, before Window-Eyes let go of the system - a behavior that in general is a clear drawback of WE. OK, my question number two, for you guys, is: Do any of you have a clue what could cause this kind of crashing, just because a Child Node is focused, when the dialog is being closed? It even happens, if there is no other activity going on, as a direct result of the Node being focused. Just this simple sample I here have described. Whether it is because I need to erase any objects before closing the Dialog, or If I am missing some essential point, I am not aware. Yet, I did try two things, with no further success. First, I started out the FillTree sub, by a line, indicating that if the parsed object - from the Dialog Handler - is empty the sub should exit immediately. My hope was, that no other attempt to fill in a closing treeview, would have fixed the trouble of crashing. Next, I tried to set the treeview control to nothing, as part of the closing routine in the Dialog Handler. None of it worked to my satisfaction. Finally, I thought, maybe it could be due to the FillTree sub trying to focus the selected node, upon each redraw of the treeview. OK, so I removed that line in the sub, and now it seems not to crash, whenever I close the Dialog. OK, any ideas as to if I could have worked around all that closing trouble? Should I have erased any further objects, or how can I make the user selected node focusing all the time, and still have the dialog closing properly? Not even On Error Resume Next, would work for troublefree closing. And, as stated above, how can I prevent the treeview from refilling everytime you tab back and forth in the dialog? Sorry for the rather long explanation. Hope someone have had some experience and found working ideas. As I said, I have looked at other codings, and thought I had done much of the same procedures as the rest of you. Yet, all this trouble. Smile. What really puzzles me, is why things in the DialogCreated section, keep repeating for each tabbing around. Maybe I am misinterpretting that instruction, but I thought it would only fire, when the Dialog is initiated, hence I could perform a "one-time" action in that section. Apparently not, so any other ideas are welcome. thanks,
