> Depending on the node-state, the menu might even be dynamic. But cases where > the node needs to be completely disabled it's just easier if the base library > handled that. That way we can also avoid replicating that code in every > user's application.
Got it. That's why I suggested filing a JIRA issue for an improvement. Thanks for that. Just curious -- what is your reason for writing 100% Java code? Our application uses ~100 bxml files and many are dynamically chosen. We found it easier to write even little bxml files for stuff rather than use Java code (if possible), although there is a bunch of pure Java code in some cases too. So, I was wondering what got you to the point of wanting only Java code? >100% pivot-code will also jump start developers relatively quickly and might >trigger adoption at a higher rate. Agreed, which is why I was wondering about your use case to consider how many others might be in the same place. Thanks, ~Roger -----Original Message----- From: Josh R [mailto:[email protected]] Sent: Wednesday, August 08, 2012 12:10 PM To: [email protected] Subject: Re: How to block UI input to a disabled/busy TreeNode On Wed, Aug 8, 2012 at 2:43 PM, Roger L. Whitcomb <[email protected]> wrote: > Hmm, my feeling is that you're doing it the "right" way by checking the node > state and not displaying a context menu if the node is "disabled". I don't > think there is a "right" answer as to whether UI input should be > enabled/disabled for a specific node if it is in the disabled state. You > might, for instance, have a different context menu depending on whether a > node is disabled (for example to enable it again in some cases) and so you > would want the UI input to get through. > Yes, totally agree. Depending on the node-state, the menu might even be dynamic. But cases where the node needs to be completely disabled it's just easier if the base library handled that. That way we can also avoid replicating that code in every user's application. If adding this functionality to the base class would be considered code-bloat then it would be really great if pivot-developers could add some extended classes to pivot-contrib. After spending almost a day on creating modal pop-ups, I found a link to pivot-contrib and saw the BlockingDialog class! So the contrib approach is nice too. That way the base classes can stay lean. IMHO, busy/active indicators and capability to enable/disable nodes would be really nice to have. > Of course, it might be possible to set a style on the tree as to > whether or not disabled nodes pass through their input, but my feeling > is that this is better left up to the user what to do..... My 2c... > You could file a JIRA issue about this and we could think about it. > Or you could implement it yourself and suggest it as a patch ;) > Ok, I will file a JIRA issue. > Again, thanks for using Pivot. > ~Roger Whitcomb Thanks for your time Roger. I like pivot's look and feel, layout etc. I personally feel that the code samples/demos should have also had parallel examples that don't use bxml at all. I am not an application developer and so it took me a while to translate the bxml to a working pivot code(100% java code). 100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate. thanks
