GUI - TabPage and Tab Issues
by Scott Peal · in Torque 3D Professional · 07/18/2009 (8:13 pm) · 6 replies
Not sure if this has been mentioned or not yet. Just in case someone is updating the GUI editor, here is my testing results for TabBook/TabPage:
1) The UI allows a user to place a TabPage on the UI even if there is no TabBook. Not sure if this should be prevented or not, but makes sense?
2) If you drop a TabPage onto a TabBook then select Dock=Client the TabPage does not dock to the client. If you click and drag the corner of the TabPage, it will then dock to the client. It would seem to me that when a user drops the TabPage onto a TabBook, the TabPage's default setting should be Dock=Client.
3) TabPage can be dropped on the last dropped TabPage. If this happens the UI should auto place the new TabPage on the existing TabPage's parent TabBook.
4) If you select an existing GUI element from the tree (top right corner) then hit delete button, you can not delete the GUI element. You have to click the element in the workspace then hit the delete key.
5) If you change the order of the TabPages via the tree (top right corner) the tabs do not change order in the workspace.
6) You cannot change the order of TabPages via the GUI. Maybe we need a order field in TabBook?
7) If you delete a tab page it is removed from the tree, but not from the workspace.
BTW, having to save ask me the name of the file everytime is annoying. Can we get just a save button which saves to our last saved location? Please :)
Hope this helps.
1) The UI allows a user to place a TabPage on the UI even if there is no TabBook. Not sure if this should be prevented or not, but makes sense?
2) If you drop a TabPage onto a TabBook then select Dock=Client the TabPage does not dock to the client. If you click and drag the corner of the TabPage, it will then dock to the client. It would seem to me that when a user drops the TabPage onto a TabBook, the TabPage's default setting should be Dock=Client.
3) TabPage can be dropped on the last dropped TabPage. If this happens the UI should auto place the new TabPage on the existing TabPage's parent TabBook.
4) If you select an existing GUI element from the tree (top right corner) then hit delete button, you can not delete the GUI element. You have to click the element in the workspace then hit the delete key.
5) If you change the order of the TabPages via the tree (top right corner) the tabs do not change order in the workspace.
6) You cannot change the order of TabPages via the GUI. Maybe we need a order field in TabBook?
7) If you delete a tab page it is removed from the tree, but not from the workspace.
BTW, having to save ask me the name of the file everytime is annoying. Can we get just a save button which saves to our last saved location? Please :)
Hope this helps.
About the author
Step 1) be the indie, step 2) make enough to buy a commercial license :)
#2
As for pages that com from nowhere, seems the tabBook can create pages on its own somehow, but since the editor doesn't sync it gets very confusing.
07/27/2009 (11:59 am)
Aside from the editing issues, they do work fine when you save them. Also, most of the problems you're seeing are due to the GUI editor tree view not updating properly for some reason... deleted nodes remain in the tree view, moved objects are still shown inside their previous parents, etc.As for pages that com from nowhere, seems the tabBook can create pages on its own somehow, but since the editor doesn't sync it gets very confusing.
#3
Did a pass on this for 1.1. Here's where things currently stand:
1) True but probably not really an issue.
2) Still needs looking into.
3) True, would be better. While confusing, it's not doing harm, though.
4) Works.
5) Works.
6) True. Think that ordering via the tree is quite adequate, though.
7) Works.
Fixed a number of other issues with editing tabbooks (most importantly the tendency to crash when moving non-page controls in and out of tabbooks; non-tabpages can no longer be moved inside of tabbooks).
Re saving: it automatically fills in the save filename of the control being saved so hitting save and return will save over the last saved file. Would you still prefer to have separate "Save" and "Save As..."?
11/05/2009 (7:41 pm)
Did a pass on this for 1.1. Here's where things currently stand:
1) True but probably not really an issue.
2) Still needs looking into.
3) True, would be better. While confusing, it's not doing harm, though.
4) Works.
5) Works.
6) True. Think that ordering via the tree is quite adequate, though.
7) Works.
Fixed a number of other issues with editing tabbooks (most importantly the tendency to crash when moving non-page controls in and out of tabbooks; non-tabpages can no longer be moved inside of tabbooks).
Re saving: it automatically fills in the save filename of the control being saved so hitting save and return will save over the last saved file. Would you still prefer to have separate "Save" and "Save As..."?
#4
2) Fixed for 1.1.
GuiTextCtrl::onPreRender was not calling Parent::onPreRender and thus not triggering re-layout.
11/06/2009 (1:28 am)
2) Fixed for 1.1.
GuiTextCtrl::onPreRender was not calling Parent::onPreRender and thus not triggering re-layout.
#5
Thanks for all the updates and fixes :)
11/06/2009 (2:17 pm)
Re saving: It would be nice to just have a typical save button that will save like what you would find in Microsoft Office products. If the file was never saved before, then ask for the file location. Just a friendly helper if you do a lot of saving like we do.Thanks for all the updates and fixes :)
#6
Yep, see your point though being the type of guy that tends to shoot himself in the foot, I liked the extra-precaution built into the way it worked. Talked this over with our resident GUI guru Jason and switched the Gui Editor to have "Save" and "Save As..." that work like in any other application.
There's a bunch of other improvements to the Gui Editor coming in 1.1, too.
Thanks Scott and keep the feedback coming.
11/06/2009 (6:04 pm)
Yep, see your point though being the type of guy that tends to shoot himself in the foot, I liked the extra-precaution built into the way it worked. Talked this over with our resident GUI guru Jason and switched the Gui Editor to have "Save" and "Save As..." that work like in any other application.
There's a bunch of other improvements to the Gui Editor coming in 1.1, too.
Thanks Scott and keep the feedback coming.
Torque 3D Owner Kenneth Holst
Default Studio Name