[HeDiBo]

Today, after the PC booted, the icons were OK

However, running the application a couple of times (I did'n't check in the mean time) the icons were distorted as before

With one exception: the documents icon was not a black square, but behaved just like the other icons: a non-functional transparency

When I run the application on another PC there is no problem

[HeDiBo]

Unfortunately, my conclusion that it was a user account problem is false.

What happens is that the SECOND time I run the application, the explorer icon cache gets corrupted.

This is the result, after I cleared the explorer cache:

[attachment=8612:IconProblemFresh.jpg]

This is how the program shows the panel upon first run:

[attachment=8610:IconProblemFirstRun.jpg]

After this, the icon cache does not seem to be altered:

[attachment=8614:IconProblemMiddle.jpg]

Then I run the application for a second time:

[attachment=8613:IconProblemSecondRun.jpg]

And now, the icon cache seems affected (look at the size and date of the iconcache_idx.db file).

[attachment=8615:IconProblemFinal.jpg]

The same thing happens when I run the application from another account.

The same thing happens with the ASkinDemo application.

The icon for Documents is always black, in each situation.

[HeDiBo]

'Support' wrote:

Try this attached file, plz.

You changes were added also.

Thanks a million.

I'm afraid the exception is back.

Using this test project: [attachment=8607:acShellBug.zip]

click on the “Select Path AC” button, then navigate to a folder and press the “Add Folder” button on the bottom. I got this exception immediately:

[attachment=8608:acShellBugException.jpg]

This was the stack:

[attachment=8609:acShellBugException.txt]

It didn't happen all the time, but if it didn't happen, a new folder was not created. An exisiting folder (not sure which) was offered for renaming (the foldername became in Edit mode).

[HeDiBo]

'Support' wrote:

Thank you for a link

Do you have pages examples which I can test? Where scrollbar is shown as not skinned.

This one is fairly short: [attachment=8605:CorrPersonsED.html]

This one is a little bigger: [attachment=8606:Participants.Pairs.html]

[HeDiBo]

'Support' wrote:

Thank you for the demo. Try this changed file.

Wow That was quick

Thanks a lot.

[HeDiBo]

'Support' wrote:

Thank you for the demo and your suggestion, I will check it soon.

I'v sent you a possible replacement for acShellCtrls.pas by private mail.

[HeDiBo]

'Support' wrote:

Hello!

I will try to do it, but my solution for hiding of std scrolls is not universal, seems.

Have you checked this code more?

I've done better than that, I've found a good solution to this.

Have a look at this article. It comes complete with a demo program. Its principle is to host the webbrowser in a specially crafted IDocHostUIHandler interface. By doing so, apparently you can show and hide the vertical scroll bar at will.

[HeDiBo]

To really make it a feasible addition to the ShellListView control, the MakeNewFolder should be augmented as follows:

MakeNewFolder should be parameterized with a parameter const NewName: String (empty if the current behavior is what is wanted). It should return a Boolean, indicating if it succeeded.

AfterNewFolder is an event, that passes the new full path name of the created folder (because its name can be changed with a sequence number, like “New Folder (3)”

This would also work:

Code:

function MakeNewFolder(const NewName: String; out CreationResult: Integer): String;

which would return the full path of the created folder or an empty string if the folder could not be created (in that case CreationResult contains the Windows error code).

That makes the thing complete and workable.

The default name for the new folder should not be “New Folder” but the localized version of that (in Dutch that would be “Nieuwe Map”). It's not easy, because the string ID changes with Windows versions. This is a good starting point for finding the localized string.

[HeDiBo]

Using Delphi XE4 I leave numerous frames open when I close Delphi.

It must be in de CX10Tokyo version, because I have no problem.

[HeDiBo]

Changing the TsPageControl in a TsPanel gives the same problem.

[HeDiBo]

'Support' wrote:

If ExtBorders is False, then width of border received from windows system.

Otherwise, this border must be changed in the skin directly.

To illustrate what I would like I have made a small test program:

[attachment=8583:TestWindowBorders.zip]

When started, it looks like this:

[attachment=8584:BorderCurrent.jpg]

When DrawNonClientArea is False, it looks like this:

[attachment=8585:BorderNoExtBorder.jpg]

What I'm looking for is this look:

[attachment=8586:BorderIdeal.jpg]

This does away with the overly wide borders but retains the title customization.

The problem stems from the TsPageControl. Without it, the borders are small as preferred.

[HeDiBo]

'Support' wrote:

But I can't recompile the demo because sources are wrong.

I made a mistake, including the wrong source.

This is the right source and I included the source for TJvDBGrid (it's public domain)

[attachment=8582:acJvGridBkgr.zip]

[HeDiBo]

Just an observation:

Every time a webpage does not fit the window, a nicely themed vertical scrollbar appears. Apparently AC is able to find out when to draw this scrollbar. Then if the page does fit the window, the themed scrollbar disappears. And it comes back again when the page does not fit the window.

Now you're saying that you do not know when to remove the standard scrollbar. But in a way AC does this already. Because when you remove the styled scrollbar, that's also the time to remove the standard vertical scrollbar.

Just a thought.

[HeDiBo]

'Support' wrote:

Thank you for the demo.

I know how to remove a scrollbar, but I don't know When I must do that.

That's the problem, I can't catch event when visivility of scrollbar is changed.

What's the best way to remove the scrollbar? Maybe I can do it myself?

[HeDiBo]

[Content was edited mistakenly by Serge]

[HeDiBo]

I came across this yesterday, and I cannot understand what makes this work.

Because basically you add two variables to TDBLookupControl. When you leave out the FDataList variable, which is not used in the source at all, it doesn't work anymore

What tricks are you playing with this? How does this work? Shouldn't there be a more civil way of getting the effect of hiding the drop down button?

Please explain

[HeDiBo]

'Support' wrote:

The sSkinProvider.AddedTitle.Font property changes font data for additional text only (the sSkinProvder.AddedTitle.Text property).

For a full control of texts in the title the TsTitleBar component should be used.

The text from the TsTitleBar is not shown, if SkinManager is not active. If the application wants to show the main caption, the font properties of the main caption should be settable if SkinManager is active.

[HeDiBo]

'Support' wrote:

We will receive a number of the Visible row in this case.

But we haven't information about of amount of records before first visible row. If grid is scrolled then rows must be moved too.

I can understand, if you think it is important that a certain background color stays with the same record. But I consider these alternate colors as nothing more than line paper. They are a reading aid to aid the user in keeping on the same line, nothing more.

Keeping the background color with the record is not possible anyway: inserting a record in the visible part of a grid will affect the background color for all rows following it.

So I think if grid is scrolled, the background color of the rows does not have to scroll too. In fact, if you have a look at the TJvDBGrid implementation in the attached project. It uses this principle and it looks completely OK:

[attachment=8578:acJvGridBkgr.zip]

[HeDiBo]

'Support' wrote:

I think, calculated fields may be used for such purposes in some databases.

I have researched standard grid controls and don't see any info about current row number, unfortunately.

So, I don't know a good solution which exists in standard grid already, all existing solutions are based on information received from DB, seems.

Have another look at the code I gave.

The background color is not related to the dataset contents, just to the row of the cell being painted. That is given by the Rect of the cell to be drawn by means of

Code:

RowNo := Rect.Top div (Rect.Bottom – Rect.Top);

It is not based on a record number or what have you.

Could you have another look at this, please

[HeDiBo]

'Support' wrote:

Hello!

This comment was added there a lot of time ago for some reasons.

I was planning to remove this comment, but forgot. Please, ignore it.

Fair enough

[Author]

Posts