#205 ooDialog - better document SetData

v4.0
closed
5
2012-08-14
2007-07-13
Jon Wolfers
No

The ooDialog SetData method can have unfortunate consequences when you have a ListControl or TabControl on your Gui.

It changes the focus to match the contents of the attribute associated with that control.

With a tab control it finds the first leaf that matches, which might not be the one that was focused before if the leaf values are not all unique.

I think it would be handy to have a SetData that you could limit to certain types of control, something like

self~setControlData('Edit CheckBox')

which would only transfer data to the controls of the type(s) enumerated in the parameter

It is natural to want to do a GetData & a SetData around a validate method for instance.

I have enclosed a little script which shows how when you run setData your tree control selection can be 'corrupted'. Select a leaf from the IDE branch, press set data & see what happens to the focus.

thanks,

Jon

Discussion

  • Jon Wolfers

    Jon Wolfers - 2007-07-13

    demonstrates problem

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-07-13

    Logged In: YES
    user_id=191588
    Originator: NO

    Jon,

    My first reaction to this was, only use setData when you want to blindly change every control for which an attibute has been added. <grin>

    I am attaching 3 adaptations of your example that use some different solutions to prevent the focus from changing. After you take a look at them and think about it, let me know if you think there still is a real problem here that this feature request would solve.

    First off, it really helps when you attach a working code example of what you are talking about.

    Now, I know the example was contrived, but lets look at what is happening here:

    ::method DoSetData
    self~getData

    That sets the treeAttribute attribute to the text of the leaf that has the focus. The text is 'Motherboard A'

    self~setData

    That loops through all the attributes created for controls and sets the control to the value of the attribute. When it gets to the tree control, it sets the selected leaf to the first leaf that the tree control finds with the text of: 'Motherboard A'

    Since you have two leafs with the exact same text, the first leaf found gets the selected focus. In this case the second leaf is the one that had the selected focus, so the focus changes.

    1.) This problem goes away if you don't have 2 leafs with the same name.

    Now, I also know that you must be having this problem in the real world, or you wouldn't be bringing it up.

    So here are 3 real world solutions you should consider. I"ve attached 3 programs that start with your example, and are altered to use the solutions. The programs are in a zip file.

    Solution A: Before you call setData, set the treeAttribute to the empty string. Then the tree control is not changed.

    / do some processing here - be sure treeAttribute is "" if you don't want /
    / focus to change. /
    self~treeAttribute = ""
    self~setData

    Solution B:

    Don't call setData, instead call setValue for each control whose value you want to change. That way you have a finer grain of control over what happens. Put the resource IDs of all your edit controls in some structure and use that with setValue.

    / only do setValue on the edit controls /
    do id over editControls
    / do some processing here /
    self~setValue(id, "Some new data here:")
    end

    Solution C

    A variation on B. When you do your processing, use some structure, maybe a table, to keep track of the value and resource ID of what you need to update.

    Then use setValue to update those controls that need updating. This is the solution I prefer and my third example program uses it. It seems to me that this would handle any real world problem you are attacking.
    File Added: setData.zip

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-07-13

    zip file of 3 solutions

     
  • Jon Wolfers

    Jon Wolfers - 2007-07-13

    An app where the tree is bound to have non-unique leaves

     
  • Jon Wolfers

    Jon Wolfers - 2007-07-13

    Logged In: YES
    user_id=667060
    Originator: YES

    Hi Mark,

    thanks for your prompt attention. This was a minor problem for me a few years back, although I worked my way around it using lots of setTitle methods. I only opened the RFE because I thought it would improve the product (especially after reading Bills contribution to the developer list). I attach a screenshot of my app & you see why it would be hard to avoid non-unique leaves.

    I would have included the code but a) it's enormous, b) you cant run it without other bits.

    The data for the tree control I took from the tree control example in the ooRexx samples directory as I didn't want to use something contrived just to make it fail.

    For myself, I'm happy to close this RFE, although I would request that your solution (A) went into the ooDialog documentation (in the setData method section).

    thanks again for all your hard work,

    Jon
    File Added: promoteUI.jpg

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-02-09

    Jon,

    I'm taking this action here: document setData a little better, noting that using setData can have adverse side effects, and pointing out some alternatives like setValue or setAttribute. Changing the title of this item to reflect a documentation enhancement.

    The more I thought about this, the more it seems to me that setValue and setAttribute already supply, mostly, this functionality.

    The whole idea of a data attribute really only makes sense for a few controls, edit controls, radio buttons, check boxes, and maybe simple list boxes. For tree-view, list-view, and all the other controls, it doesn't make sense. I wish the original developers had not included data attributes with the new controls when they added them. It is really trying to force a square peg in a round hole.

    What I'd really like to do is steer users away from using data attributes with those controls where it doesn't make sense.

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-02-09

    Committed revision 4112.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-09-16

    This request for a feature enhancement has been included in a prior release so the tracker item is being closed.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks