Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS General Discussion » DockBar Button Position Collapse All
Subject Author Date
Andreas Schneider Sep 11, 2007 - 3:40 AM

Hello Prof-UIS Team,

when you have multiple CExtControlBars that are docked e.g. on the right side, and you press the pin of on of the CExtControlBars, so that it doesn’t slide away. The Button of this CExtControlBar is no longer shown in the DockBar.
If you press the the pin again (so that the Bar can slide away), the Button appears at the Bottom of the DockBar instead on it’s old position.

I have 2 questions:
1) Is it possible to have the Button always on the same position.
2) Is it possible to let the Button stay in the the DockBar while the Bar is pined, and only disapear, when the Bar is floating ?

Best regards,
Andreas

Andreas Schneider Sep 28, 2007 - 1:43 AM

Thank you for your response.

Can you estimate if the feature will be in this year or will it take until next year ?

Andreas

Technical Support Sep 27, 2007 - 2:32 PM

Right now we are working on the next release and are not sure if we will have time to add this feature now. But we are sure we will add it in the next release.

Andreas Schneider Sep 27, 2007 - 9:03 AM

Hello Prof-UIS Team,

Any ideas ?

Best regards,
Andreas

Andreas Schneider Sep 20, 2007 - 1:28 AM

>Should we save/restore priorities of control bars?

For our application this is not important. We can set the priority at Control Creation time.

>How exactly should be sort tab groups and tabs in each group?

Inside each group the priority could be used, and and the group tab itself, could for example use the highest priority in the group
(In our case we don’t care, because we only care about non-grouped Button positions)

>How grouped tabs should behave if your code very often changes control bar’s priorities on timer?
Good question. I would say, don’t change priorities in a timer. It’s as bad as a lot of other things, you shouldn’t do in a timer.

I’m sorry to ask, but do you know if you’ll be able to implement it until the end of this month?
Because otherwise I have to hack it into Prof-UIS myself. I would appreciate any comments.




Technical Support Sep 19, 2007 - 1:26 PM

This feature is not implemented yet and it needs to be discussed in more details first. For instance:

Should we save/restore priorities of control bars?

How exactly should be sort tab groups and tabs in each group?

How grouped tabs should behave if your code very often changes control bar’s priorities on timer?


Andreas Schneider Sep 19, 2007 - 10:52 AM

>But it is possible we have a reason to assign some importance ranks to each control bar and build a sequence of grouped tabs according to >importance marks.

Is it already possible or do you have implement it first ?

If you have to implement it, do you know how long it will take, until I could use it ?

Andreas Schneider Sep 12, 2007 - 5:50 AM

Sorry, maybe I was not clear enough.
It is not a bug. It’s working in the way you wanted it.
My question is, if it is possible to change the way it behaves with a flag, so it is more like a request for a new feature (or maybe already existing feature).

To reproduce it:

1) First go in ProfStudio on the "Memory 1"-CExtControlBar and press the Pin, so that it doesn’t Autohide anymore.
2) Then you press the Pin again, so that the Bar does Autohide again

When you do 1), you can see that the 4-memory-Buttons on the DockBar disapear.
Our wish would be that the Buttons stay in the DockBar, until you make the "Memory"-Bars Floating.

In case 2) If you make the Bars Autohide , the Buttons appear on the DockBar again, but not on the Position they were before (on the left side from the "Object Browser"-Button), but on the right side.
Is there a way to let CExtControlBars-Buttons appear always at a fixed ordering ? E.G. Memory-Buttons are always on the left side from the "Object Browser"-Button. E.g. each Bar could get an SortIndex when it is created, and the buttons of Bars with a lower SortIndex are always positioned before the one with a higher SortIndex.

Andreas




Technical Support Sep 13, 2007 - 11:40 AM

We implemented the auto-hide area behavior similar to that in Visual Studio .NET and Visual Studio 2005. We are not sure the tab groups should appear in some order which depends on the location of control bars because as you know they can be organized into a complex nested layout. Generally the layout of docked control bars can hardly possible have a look of some linear data structure like grouped auto hide area. But it is possible we have a reason to assign some importance ranks to each control bar and build a sequence of grouped tabs according to importance marks.

After a long delay, we improved control bars for the next version. Now they support caption flashing feature. It is possible to make the caption of a control bar flashing when some event related to bar’s child windows occurs and the user should not miss this. The flashing effect is supported for the control bar’s caption, floating frame’s caption, a tab item in a tabbed bar group, a tab item in the grouped auto-hide tabs area, MDI tabs and tab page container’s tab items in the case of dynamic resizable control bar. So, if you need to pay attention of the user to some control bar, you can flash it. We guess this feature may have something to do with some of your requirements.

Technical Support Sep 11, 2007 - 9:32 AM

Could you let us know how can we reproduce this problem using our ProfStudio sample, which has lots of control bars? Are you using any idle time processing or timers that perform heavy operations? Could you send us a screenshot demonstrating an incorrect location of the button?