[HeDiBo]

'Support' wrote:

I can add the blCentered parameter soon. Text will be centered also, in this case.

OK. But have a possibility to flow around the glyph, not beneath it.

[HeDiBo]

'Support' wrote:

Some new properties will be added in the nearest release.

What is purpose of the Transparent property there?

The same as it is in TsSpeedButton.

[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?

[HeDiBo]

'Support' wrote:

Hello

The problem is that I can't get it wrong too.

Maybe you can give some more info:

Maybe, this error occurs only in specified directories?

I found that it only occurs if I run my project in the Delphi developer environment. When ran as stand-alone it does not occur.

If it occurs it's when a sub directory is selected in the left pane.

More than the detailed stack and the source locations where the bug occurs I cannot provide.

[HeDiBo]

'HeDiBo' wrote:

That would also give the possibility of a transparent image in the middle with texts on both sides

Did you consider this? It's not in 12.18.

[HeDiBo]

'Support' wrote:

Sorry again )

This procedure and some new properties will be available in the nearest release.

These properties would be nice also: Blend, Glyph, Transparent, and UseEllipsis. Now only the special ImageIndex properties and the WordWrap property are implemented in 12.18.

Especially the Glyph property is very useful if you have only one image.

[HeDiBo]

Problem stll exists in 12.18.

I don't understand the purpose of the extra setting of scLeftLeft.

It does not solve the problem with Layout = scTopLeft.

Or maybe I need some clarification.

[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.

[HeDiBo]

'Support' wrote:

Hello and thank you for the detailed report with a demo.

I will add some changes in the code in the nearest release and I hope it helps.

Problem still in 12.18

[HeDiBo]

'Support' wrote:

I will try to change it in the nearest release.

Solved in 12.18

[HeDiBo]

'Support' wrote:

You are right, I see a problem now. I will fix it on the next week.

Replacing skins with local names still does not work. I thought.

But when I removed the translated ones, added them again and translated them again, then it worked.

[HeDiBo]

'mol' wrote:

Try this one, Dick:

http://www.swissdelp…code.php?id=586

Thanks, I already found that one. It sets the bar for every message that reaches the listview. A total overkill and it has the danger of getting in a loop, because it assumes that setting the bar will not result in any message to the ListBox.

In the mean time, Serge has come up with a different approach: although the column is set to AutoSize, the listview still needs this set all the time:

Code:

ListView_SetColumnWidth(Handle, , LVSCW_AUTOSIZE_USEHEADER);

which appears to do the same

However, doing it this way my problem is solved:

Code:

TsListview = Class( sListView.TsListview )
protected
procedure WMPaint( var msg: TMessage); message WM_PAINT;
end{class override};
.
.
uses Winapi.CommCtrl;
.
.
{$J+}
procedure TsListview.WMPaint(var msg: TMessage);
const
inpaint: Boolean = False;
var
i: Integer;
begin
if not inpaint then begin
for i := 0 to Columns.Count – 1 do begin
if Columns.AutoSize then begin
inpaint := True;
ListView_SetColumnWidth(Handle, i, LVSCW_AUTOSIZE_USEHEADER);
inpaint := False
end{if};
end{for};
end{if};
inherited;
end;
{$J-}

It's very weird, but it works.

Thank you, Serge, for finding this

[HeDiBo]

'Support' wrote:

Hello!

It was another problem.

Your problem is inherited from standard TListView component and I will try to solve it soon.

You're in for a real treat.

I searched for two days now for a solution to hide the horizontal scrollbar in a standard TListView: it simply is not possible (none of the suggested solutions worked), since it is a very old flaw in the Windows implementation.

The closest I got was this:

Code:

// Make WMPaint accessible

TsListview = Class( sListView.TsListview )
protected
procedure WMPaint( var msg: TMessage); message WM_PAINT;
end{class override};
.
.
.
// Every time hide the scrollbar, but disable it too, because now and then it still appears during manual scroll.
procedure TsListview.WMPaint(var msg: TMessage);
begin
EnableScrollBar( Self.Handle, SB_HORZ, ESB_DISABLE_BOTH );
ShowScrollBar(Self.Handle, SB_HORZ, FALSE);
inherited;
.
.
.
// During Form/Frame initialization:
.
.
ShowScrollBar(sListView1.Handle, SB_HORZ, FALSE);
.
.

It's not pretty at all

In AC there may be an extra possibility. Since AC has to draw the scrollbars itself, it may prevent drawing scrollbars using the information of an extra property (SB stands for Scrollbar, LV stands for ListView):

SBVisibility: TLVSBVisibility

Where TLVSBVisibility is: (LVSBStandard, LVSBBoth, LVSBHorz, LVSBVert, LVSBNone}

in which LVSBStandard would be default and mean: don't change the scrollbar behavior.

I look forward to such a solution.

[HeDiBo]

'Support' wrote:

Thank you, it was my mistake. ASkinDemo has been compiled and autosaved in the Delphi 10 and I forgot about that.

OK.

[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:

Thank you for the message, this memory leak will be removed in the nearest release.

Solved

[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

[HeDiBo]

'Support' wrote:

Hello!

Thank you for the demo, this issue will be solved very soon.

Solved in 12.16

[HeDiBo]

'HeDiBo' wrote:

A TsListView with auto width column shows a horizontal scrollbar but it should not (column width is automatic):

[attachment=8441:ListViewBug.jpg]

Contrary to the release notes, this problem is not solved in AC 12.16

This problem only occurs if the Columns[n].AutoSize is True

[HeDiBo]

'Support' wrote:

Hello

This component has been updated in the v12.14, you can try it again.

It works now. Thank you

[Author]

Posts