strange behaviour of ParentBarItem in combination with MainFrameBarManager

[thomas.neumeier]

Hi, we are using syncfusion 1.6.1.8! 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? Regards Thomas Neumeier syncproblem0812_9895.zip

[Arun Srinivasan]

Hi Thomas, 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. Regards, Arun forums_9131_5220.zip

[thomas.neumeier]

Hi Arun,

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

[Administrator]

Hi Thomas

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?

Regards
Arun

[thomas.neumeier]

>Hi Thomas > >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? > >Regards >Arun > Hi Arun, 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 syncproblem1112_3841.zip

[Administrator]

Hi Thomas

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.

Regards,
Arun