[HeDiBo]

The demo program shows this:

[attachment=8440:FrameBarBug.jpg]

With these settings, clicking a title does not show the frame anymore.

[HeDiBo]

'HeDiBo' wrote:

The demo program shows this:

[attachment=8440:FrameBarBug.jpg]

With these settings, clicking a title does not show the frame anymore.

Problem not solved in AC 12.16

[Support]

Titles in this component are implemented by SpeedButtons.

Standard dragging way used in these buttons and has a standard behavior.

Standard button can't clicked if DragMode is dmAutomatic.

This is a reason why title can't be clicked when DragItems is True, I will think how to avoid it, but can't promise a success because implementation of dragging has low level in VCL and can't be changed.

[HeDiBo]

'Support' wrote:

Titles in this component are implemented by SpeedButtons.

Standard dragging way used in these buttons and has a standard behavior.

Standard button can't clicked if DragMode is dmAutomatic.

This is a reason why title can't be clicked when DragItems is True, I will think how to avoid it, but can't promise a success because implementation of dragging has low level in VCL and can't be changed.

Hi Serge,

Clicking a title in a frame bar should show the frame. Otherwise the frame bar has no reason to exist.

If it cannot be solved (I really doubt that), the property DragItems should have reduced visibility from Published to Public. A programmer will not make the mistake setting it, but there's still a possibility to set it programmatically in specific and temporary situations.

[HeDiBo]

'Support' wrote:

Titles in this component are implemented by SpeedButtons.

Standard dragging way used in these buttons and has a standard behavior.

Standard button can't clicked if DragMode is dmAutomatic.

This is a reason why title can't be clicked when DragItems is True, I will think how to avoid it, but can't promise a success because implementation of dragging has low level in VCL and can't be changed.

It's not solved in 12.18

If it cannot be solved, remove the DragItems property altogether. It makes the TsFrameBar unusable.

You might also move the visibility to Public. That means programmatically you can still enable dragging in some way. But you have to reset it upon DragDrop. An ugly solution.

[Support]

'HeDiBo' wrote:

If it cannot be solved, remove the DragItems property altogether. It makes the TsFrameBar unusable.

The Visible property can make the component unusable too 🙂

The behavior of the component is depended from developer in this cases, I think.

Maybe someone have own opinion and can share it here? The DragItems property should be Published or Public?

[HeDiBo]

'Support' wrote:

The Visible property can make the component unusable too 🙂

The behavior of the component is depended from developer in this cases, I think.

Absolutely. But making a component unusable at design time without the designer knowing what causes the problem (having a drag and drop functionality seems like a usable thing) that's a bit too much.

Visibility is not a good example, because the name Visible suggests its functionality. The property DragItems does not suggest the component will not work anymore if set to True. Maybe it should be called DisableExpand?

Having said that, what is the purpose of DragItems?

[Support]

A purpose of this property is switching of the component to the special editing mode where order of items may be changed by user.

[HeDiBo]

'Support' wrote:

A purpose of this property is switching of the component to the special editing mode where order of items may be changed by user.

Now that the property is gone from Published to Public, it may be a good idea to implement the event OnAfterDragItem so that the programmer can reset the DragItems property.

[Author]

Posts