|
Add or Remove Buttons vs Customize Dialog |
Post Reply 
|
| Author | ||||
dajv 
Groupie 
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: Add or Remove Buttons vs Customize DialogPosted: 18 January 2006 at 12:57am |
|||
|
In order to prevent menu items from being shown in the "Add or Remove Buttons" context menu of the toolbars, I call EnableCustomization before this menu is shown, then the controls that have visible = false will not show.
If I move a control on the toolbar, then go to the "Add or Remove Buttons" context menu and select "Reset" from the toolbar "standard" popup menu, the control i moved goes back to where it should (back to the state of the toolbar since the configuration was last saved). Thats good. I also call EnableCustomization before the customise *dialog* is shown, for the same reason as above. But if I move a control as before, then go to teh customise dialog - select the toolbar "standard" from the list and click the "Reset..." button, the control is not moved back to where it was before I moved it. Is this a bug? (silly question :) .) I also wonder about what the user expects out of the reset button. Should it reset to the application default menu configuration, or back to the way it was last saved? We provide the user with a way to reset the configuration completely, to go back to the default menu layout. But as a user I would probably expect the Reset button to reset the menus back to the application default menu configuration. Can someone comment on this? Thanks |
||||
 |
||||
|
Oleg
Admin Group 
Joined: 21 May 2003 Location: United States Status: Offline Points: 11234 |
Post Options
Thanks(0)
Quote Reply
Posted: 18 January 2006 at 1:28am |
|||
|
very bad idea to call EnableCustomization before customise dialog. It must be called only once to save state. Reset button restore last state of EnableCustomization call. |
||||
|
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS |
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 18 January 2006 at 4:43pm |
|||
|
Well I have two options to ensure that hidden menu items are not shown on the "Add or Remove Buttons" menu.
Call EnableCustomization on ToolBarContextMenu so that controls that are hidden do not appear in the toolbar submenu of the "Add or Remove Buttons" menu. Or, call EnableCustomization each time the toolbar changes (ie some of the controls are hidden or shown). As I would expect is pretty standard among many applications, certain buttons are hidden from the user depending on the context they are in. These hidden controls SHOULD NOT appear in either the toolbar submenu of the "Add or Remove Buttons" menu or when the customize dialog is shown. I have gone to the trouble of writing code to restore menu state after the customize dialog is shown, only to find that these buttons are always accessible in the toolbar submenu of the "Add or Remove Buttons" menu. It seems I have no control over this menu. The crux of the problem is that if I call EnableCustomization each time the menu is changed, then the toolbar reset becomes useless. It will only reset to the point where EnableCustomization was last called, and that is going to be pretty often as the user moves around the application (again, this should be pretty standard to most applications - there is nothing special about changing the menus visible buttons depending on context). So either you need to provide a way of specifying which controls should appear in the toolbar submenu of the "Add or Remove Buttons" menu (and, less importantly, when the customize dialog is shown), *or* (a much better solution) provide an option that will prevent hidden controls from being shown in the toolbar submenu of the "Add or Remove Buttons" menu and customize dialog. For the "Reset" button to be of *any use at all*, the above needs to happen. |
||||
|
||||
|
Oleg
Admin Group
Joined: 21 May 2003 Location: United States Status: Offline Points: 11234 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 January 2006 at 12:09am |
|||
|
You write a lot, but I don't understand your problem. Simply point - - You _must_ call EnableCustomization only once after you create toolbars. - Buttons with Visible = False not appear in ""Add or Remove Buttons" menu" There is problem? |
||||
|
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS |
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 January 2006 at 12:34am |
|||
Here is a picture, also: 
2006-01-19_003424_DesignerSample.zip |
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 January 2006 at 3:41pm |
|||
|
Please let me know if you're looking at this or if I need to make it any clearer.
|
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 January 2006 at 6:40pm |
|||
|
Also, regarding hiding the Add Or Remove Buttons menu, in this thread,
https://forum.codejock.com/forum_posts.asp?TID=2686&KW=expan d someone asks how to hide the "expand button" so as to hide the Add or Remove Buttons menu. As the property name suggests, ShowExpandButtonAlways only applies when the commandbar does not fit in the window. In this case, setting ShowExpandButtonAlways to false will only hide it when there is enough room to show the commandbar. Otherwise the user can still access the Add Or Remove Buttons menu. Is there a way to hide the Add or Remove Buttons menu all the time, without stopping the user from accessing controls on the commandbar that can't be shown because there isn't enough room? This would be a last resort if the problem outlined in the above posts can't be fixed. |
||||
|
||||
|
SuperMario
Admin Group
Joined: 14 February 2004 Status: Offline Points: 18057 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 January 2006 at 7:23am |
|||
|
Actually, ShowExpandButtonAlways always hides the dropdown button. This will not stop users from accessing button when the window is too small...a different type of button is shown then. This will not stop users from accessing buttons that were visible when the window was expanded.
|
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 January 2006 at 6:00pm |
|||
I'm just repeating what we already know here, but when ShowExpandButtonAlways is True, the expand button is shown always. When there is not enough room to show all the controls, the expand button is also shown. The only difference is that it now also shows controls that can't fit in the window. ShowExpandButtonAlways = False simply stops the expand button from being shown when there is enough room to show all the controls. When there isn't enough room, the expand button is present. There needs to be a way of hiding the Add or Remove Buttons menu if the problem I have outlined above cannot be addressed. |
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 21 February 2006 at 6:50pm |
|||
|
Can I please get an answer to the below? There is no way for me to work around the problem, and it really does need to be fixed before we release our software.
|
||||
|
||||
|
Oleg
Admin Group
Joined: 21 May 2003 Location: United States Status: Offline Points: 11234 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 February 2006 at 7:57am |
|||
|
Replace it to CommandBars.LoadDesignerBars to fix it. |
||||
|
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS |
||||
|
||||
|
dajv
Groupie
Joined: 27 July 2004 Location: Australia Status: Offline Points: 80 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 February 2006 at 6:27pm |
|||
Your fix is something I had considered (if you read the previous posts I have made in this thread). What it means is that whenever the visible state of a control needs to be changed, I need to call EnableCustomisation. As I said here:
The visible state of controls change depending on the context a user is in. Lets take Outlook as an example of this. 1) Go to Inbox. Assuming you haven't customised the toolbar, the following toolbar will be shown: 
2) Go to Calendar. Assuming you haven't customised the toolbar, the following toolbar will be shown: 
This is a pretty standard way for an application to behave. CodeJock needs to support this behaviour. (Edit: What I mean by support, is that when you Reset the toolbar in Outlook, it does NOT show the menu items from Calendar if you are in Mail, for example. With the CodeJock CommandBars, this DOES happen, as I showed in previous screenshots.) The thing to notice here is that the toolbars are different based on the context. One is in Mail, the other is in Calendar. The user can go back and forth between these. This means the visible state of the controls needs to change. Using your fix, this means calling EnableCustomization after every change. This means that whenever the user "resets" their toolbar, the point it will be reset back to will be the last time the visible state of a control changed. Since this is going to be often, the reset becomes useless. All this is a reiteration of things I have already said in previous posts in this thread. I feel we are going around in circles here. This is something that really needs to be fixed, and I can imagine we are not the only ones who suffer from this - if others were to test their this part of their application they would see this is how the CodeJock control behaves. We are getting close to release and we cannot release our software with this bug. Here is what I propose: You provide a setting to hide the "Reset" button on the customise toolbar menu. This means that the only way a user can reset is by using the Customize dialog. Remember that the problem we are talking about here is caused by being able to reset the toolbar from this menu. See my previous posts for more information about this. |
||||
|
||||
|
Oleg
Admin Group
Joined: 21 May 2003 Location: United States Status: Offline Points: 11234 |
Post Options
Thanks(0)
Quote Reply
Posted: 24 February 2006 at 8:27am |
|||
|
There is nothing to fix, you just don't understand basic idea. Reset button do the thing that it must do - Revert all changes was done after last EnableCustomization call. See this sample and make same in your application.
|
||||
|
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS |
||||
|
||||
|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
Topic Options
oleg wrote: