we are using syncfusion 126.96.36.199! Take a look at the attached example. It represents the structure of our application. If you press button1 in this example, you can see the effect, with which we''ve a problem:
Every time, when the state of the with the ParentBarItem linked BarItem is changed, the subform fills for a short moment the whole client area (even the space, where the subitem has been). This short changing of the size also takes effect on the controls of this client area, they also track this movement of the subform. It''s the same behaviour (like in the application I''m developing), if subitmes of a ParentBarItems are replaced by other subitems during runtime. How can this behaviour be avoided?
ASArun Srinivasan Syncfusion Team December 8, 2003 12:43 PM
Thank you for uploading a sample. To better explain the reason for this behaviour, kindly take a look at the enclosed screenshot. If you dock bar2 as shown and then press the button you can now see how your sub form gets correctly redrawn.
The reason for this behaviour is that after you hide the baritem the bar size gets reset and recalculations take place to ensure that everything is drawn correctly. This seems like a special case as there is an empty container control (bar2 without any baritems), and hence you see this behaviour. Also automatically hiding bar2 is not correct as users may want to customize it by dragging other baritems to it. So as you can see it is not incorrect behaviour or a bug, but more of a special case.
If you could elaborate on what your needs are and what kind of behaviour you are looking for we could suggest something to work around this issue.
THthomas.neumeierDecember 10, 2003 05:31 AM
refering to your message, i have following requirement for my application:
I''ve to redraw the complete bar during runtime with new Icons and Items. During this action I want to avoid the up-and-down-movement of the subform. This unsteadiness of the subform is uncomfortable for the user and is the reason for wrong attached ContextMenus, that we''ve connected to objects on this subform.
I''ve found one way to avoid this behaviour. Before I replace the BarItem I insert a dummy-item, that I remove after the replacing. But this workaround works only, if that bar is docked on the top of the subform, but doesn''t, if it''s docked beside the subform.
Is there a other way to avoid this behaviour?
Best regards Thomas
ADAdministrator Syncfusion Team December 10, 2003 03:15 PM
Thanks for the update. Another workaround to take care of this issue when docked on the side could be to add the bar with the maximum width first. This way the there will be no flicker when you add bars that are smaller.
Is this something you can do in your application?
THthomas.neumeierDecember 11, 2003 06:55 AM
>Thanks for the update. Another workaround to take care of this issue when docked on the side could be to add the bar with the maximum width first. This way the there will be no flicker when you add bars that are smaller.
>Is this something you can do in your application?
that might be a good idea, I could try. But I really don''t, if this will solve my problem. Therefore I''ve attached a code sample that shows exact my problem.
There I already use a similar workaround, and there''s still that flickering.
I don''t think that it would have worked, if I had added a bar with the maximum width, like you had proposed.
But I''ve to admit, that I didn''t find a way to detect the size of a BarItem (the BarItems we use have a string and an icon). If you really think this workaround works, could you tell me, how to retrieve the width of a XPMenus.BarItem.
Or is there any other way to solve that flickering problem?
Best Regards Thomas
ADAdministrator Syncfusion Team December 11, 2003 08:37 PM
Thanks for the sample. One way you could get the maximum size is by checking for the number of characters in the baritem''s text.