Tree widget scroll bar

-1

Hi,

I have the following code in eg. a button detail-trigger.

vTreeRepr = $fieldvalrep(rubtrad.myent)
;do something with vTreeRepr
$fieldvalrep(rubtrad.myent) = vTreeRepr 
rubtrad.myent = "1"    ;Set to begin of tree, as here "1" is the first key-value.

If the tree is big this doesn't work fully out, as the scroll bar isn't set to the top of the tree, although the "cursor" is set to the first node.
Leaving away $fieldvalrep(rubtrad.myent) = vTreeRepr, its working correctly. So making another button and doing two clicks will work.

I found some kind of bug report about this, but the problem was then using $valrep, which now seem to work, however I can't use that. There was also a workaround using the Asynchronous Interrupt-trigger, but it didn't work with $fieldvalrep, ie. one should trick Uniface by setting rubtrad.myent = "1" in the Asynchronous interrupt-trigger and do a postmessage.
(Unfortunately I can't find that bug-report anymore.)

Has anyone had the same problem, is this just a problem of my Uniface 9.7.04 or does eg. Uniface 10 have the same problem? Is there a workaround?

Regards RogerW.

uniface-version-9

Comment

CommentAdd your comment...

3 answers

1
0
-1
Roger Wallin
Jan 12, 2021
Hi,
just a short comment on this. The bug-report I am talking about is at
RI-2331 - Tree does not scroll selected item into view Fixed
Its always working for me setting ASYNCHGUI=2, but not using the first workaround with postmessage and asynchronous interrupt trigger. I mean the first workaround "postmessage and asynchronous interrupt trigger" doesn't work if you leave ASYNCHGUI=0 or 1, with ASYNCHGUI=2 it works even without workaround.
Regards RogerW.
Comment
Roger Wallin
Jan 13, 2021
Hi,
any comments about ASYNCHGUI parameter appreciated. It doesn't look that easy to set it to 2 in a large application.
Manual:
Improve form appearance for applications using widgets with large ValRep lists.
Be aware of the following side effects:
The application performance might be adversely affected, because forms are repainted more often.
Automated testing might fail, for example, when you use tools such as QA Run.
In rare cases, painting a form might leave gray areas; these can be removed by resizing the form or clicking on the form.
The behavior of the Field Gets Focus trigger and the Value Changed trigger in tab forms might be influenced.
A popup form that has its Auto Close property set to True, cannot be activated when AsynchGui is 2 (Flush).
It is highly recommended that you test your application for these side effects when you enable AsynchGui.
CommentAdd your comment...
1
0
-1
Roger Wallin
Jan 08, 2021
Hi Daniel
What I actually do is expanding the tree before "going" to the first node, ie putting a minus before all the kind of nodes that are available in the tree. Perhaps there are better ways to expand the tree. On the other hand I don't think that's the problem.

variables string vTreeRepr endvariables vTreeRepr = $fieldvalrep(rubtrad.myent) vTreeRepr = $replace(vTreeRepr, 1, "-NODE", "NODE", -1) ;Dont get two minus vTreeRepr = $replace(vTreeRepr, 1, "NODE", "-NODE", -1) vTreeRepr = $replace(vTreeRepr, 1, "-OBLIG", "OBLIG", -1) vTreeRepr = $replace(vTreeRepr, 1, "OBLIG", "-OBLIG", -1) vTreeRepr = $replace(vTreeRepr, 1, "-CHOSEN", "CHOSEN", -1) vTreeRepr = $replace(vTreeRepr, 1, "CHOSEN", "-CHOSEN", -1) vTreeRepr = $replace(vTreeRepr, 1, "-NOLEAF", "NOLEAF", -1) vTreeRepr = $replace(vTreeRepr, 1, "NOLEAF", "-NOLEAF", -1) $fieldvalrep(rubtrad.myent) = vTreeRepr show rubtrad.myent = "1"

I have tried both with and without show. I have also tried the workaround described in a bug-report, ie. using the Asynchronous Interrupt and a Postmessage. But no improvement.

;Asynchronous interrupt if ($msgid = "SetTreeValue") ;TreeField = Value rubtrad.myent = "1" show endif

However, I have now made two buttons "Arrow_up" and "Arrow_down" that calculates the first node-key resp. the last node and just do eg. rubtrad.tubvtxt1 = "1".
The user can now quickly move (and immediately see) to the first node, ie. using one click on the Expand-button and then a new click on the Arrow_up-button. That's perhaps a bit easier than to have to use the scroll-bar.

Let's leave it like this now. We have to migrate to Uniface10 during spring and I will then see how Uniface10 reacts. Actually the code has already been migrated (test-purpose) so I could test it on Uniface10 by moving the changes there.
However if Daniel or someone else notice something, just let me know.
As Daniel says, there is probably more factors influencing this. My tree-widget is attached to the Window-border, Bottom Right, but that doesn't seem to matter.
Uniface 9.7.04.02 (G401 0830_1).
Regards RogerW.
Comment
Daniel Iseli
Jan 08, 2021
Thanks RogerW.
Tried this as well and it's still working correctly for me. I guess I'm still missing some pieces of the puzzle here. Sorry.
Regards,
Daniel
CommentAdd your comment...
1
0
-1
Daniel Iseli
Jan 06, 2021
Hello RogerW,
I did a quick test here with a ValRep that contains about 25000 items. And then I've added more items using your code as basis. So far I could not replicate the problem - even when using Uniface 9.7.04. The first item is always scrolled into view, as expected.
I guess there are more factors influencing the behavior here, than just the simple $fieldvalrep assignment in your code. Did already try to add a show statement after $fieldvalrep?
Regards,
Daniel
Comment
CommentAdd your comment...