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,
