[HeDiBo]

'Support' wrote:

Please try the original ASkinDemo: http://www.alphaskin…s/askindemo.zip

DirectoryEdit with these icons is existing on the first opened frame.

Do you have same issue there? This information is required for localizing a problem.

The directory edit from the SkinDemo app does not have a vertical bar at the left hand side. I changed the ShowRootBtns to True. Now I have the same rendering problem. With one exception: the Documents icon does show, but all four icons have a black in stead of a transparent background.

The icons on the TsFileNameEdit do look OK.

[HeDiBo]

'Support' wrote:

Hello!

I'm trying to recompile your demo-project for receiving this issue, but selection painted correctly there.

Maybe you have changed the demo? Can you give me the new demo with this problem, please?

Did you click the “Select Path DX” button?

Because the app still gives the same problem here.

[HeDiBo]

I found a more convincing case of this bug.

Controls don't look skinned at design time upon first load of a project in the IDE. And they continue to look wrong as long as you do not change their skin.

Explicitly switching their skin section and switching it back reveals how they should look.

That has been done with the button with skin BUTTON_HUGE in the picture below:

[attachment=8552:SkinAtDesign1.jpg]

This is how the controls on this frame should look like in design time:

[attachment=8553:SkinAtDesign2.jpg]

When still at design time the central skin manager's skin is changed, all controls look all right again.

[HeDiBo]

Today I retried the standard TShellTreeView and the message 'Cannot terminate an externally created thread' did not occur anymore. I suspect all my testing yesterday left the shell in some mess. So for the time, consider this bug closed

[HeDiBo]

'Support' wrote:

Here is a new changed file with delayed destruction of threads.

Maybe something went wrong. This is the same file as before.

Also, the problem did not occur in the AC version, it occurred in the standard version!

Thanks!!

[HeDiBo]

'Support' wrote:

Try the attached file, please.

WOW

Must have been a heavy task, considering the number of changes w.r.t. the previous version. And for AC it does seem to work .

Unfortunately, now I get a problem with the standard TShellTreeView:

Code:

First chance exception at $73EACBB2.
Exception class EThread with message 'Cannot terminate an externally created thread'.
Process acShellBug.exe (13536)

This problem occurs if you do a couple of different directory clicks in the standard shell tree view. The only thing that may tie this to AC is the fact that the shell controls are placed on sPanels (the stack list contains the message processor in TsPanel).

However, I changed the TsPanels to standard TPanels and the same problem occurred.

[HeDiBo]

I have another important observation: if the TsShellTreeView has property Root set to rfMyComputer there's no problem.

I still suspect the Google Drive at the top of the tree (Root set to rfDeskTop) to be the culprit.

[HeDiBo]

I produced a test project, that will show you the exception.

The main form allows for three ways to view the shelltreeview and shelllistview.

If you use the standard controls (Select Path Std.) and press Select then terminate the program, you will find the Memory Leaks,

If you use the DevEx version and press Select and then terminate the program, all goes well.

If you use the AC version all kind of things may happen. It may break before showing anything in TacShellChangeThread.Execute as described above, it may break with an exception in the standard _Halt0 procedure or it may occasionally work.

All three screens have an Exit button. This let's the main program terminate immediately (that will show a bug in the AC version also).

At the moment I'm unable to run the AC version. It will always break with an exception in TacShellChangeThread.Execute. But sometimes I have it running!

To get the AC bug when the path and list do show, choose a folder and press Select, choose another folder and press Select, etc. until it fails.

I tried the program outside the Delphi environment and could not get it to break. So it is a timing problem that will occur on slower machines (the Delphi debugger takes a long time handling threads).

[attachment=8546:acShellBug.zip]

[HeDiBo]

'Support' wrote:

Can you replace the TsShellListView by the standard TShellListView component and check him for this issue?

If issue will not occurs then I can compare the code of these two components, maybe I will have some ideas.

Replacing it with the standard components showed no problems anymore, except for a number of leaked memory areas, which were expected because in this case the thread is only terminated but not freed.

[HeDiBo]

It's still not OK.

I'm trying to find further cause.

[HeDiBo]

'Support' wrote:

Can you replace the TsShellListView by the standard TShellListView component and check him for this issue?

If issue will not occurs then I can compare the code of these two components, maybe I will have some ideas.

When I did that, I got an error in this procedure:

Code:

procedure TfrmSelPathAC.SetCurPath(const Value: String);
begin
FCurPath := Value;
sShellTreeView1.Path := Value;
if ( not (csDestroying in sShellTreeView1.ComponentState) ) and
( sShellTreeView1.SelectedFolder <> nil )
then sShellListView1.SetPathFromID(sShellTreeView1.SelectedFolder.AbsoluteID); <<== SetPathFromID is unknown

So I changed it to

Code:

then sShellListView1.Root := sShellTreeView1.SelectedFolder.PathName;

which resolved the problems

Maybe you should have a look at SetPathFromID in TsShellListView.

[HeDiBo]

I may have some indication where things go wrong.

The first path that I select is a Google Drive directory.

If I choose a normal directory, it seems to go OK.

However this use of the Google Drive (or DropBox or MyDrive) is essential for my application to allow users to share the database.

So this really must be solved .

[HeDiBo]

My program needs to use the TsShellListView two times in a row. When using it once, many times it goes OK.

But using it twice, results in a bug, so profound that it terminates the Delphi IDE itself

As soon as the second TsShellListView should appear (there is a user reaction before that, so you would expect threads to have terminated) Delphi throws this exception:

[attachment=8541:system exception.jpg]

Upon clicking Break, the debugger goes throws mayhem:

[attachment=8542:system exception2.jpg]

the exception occurs in this part of procedure TacShellChangeThread.Execute;

Code:

EnterCriticalSection(CS);
if FWaitChanged then begin
FindCloseChangeNotification(FWaitHandle); <<<=== point of exception
FWaitHandle := ERROR_INVALID_HANDLE; <<<=== upon exception this is the point of execution
FWaitHandle := FindFirstChangeNotification(PChar(FDirectory), LongBool(FWatchSubTree), FNotifyOptionFlags);
FWaitChanged := false;
end;
LeaveCriticalSection(CS);

Because the debugger got an exception, I don't know if this call stack is still valid:

[attachment=8543:system exception3.jpg]

The destructor TacCustomShellChangeNotifier.Destroy is still your version.

I tried to change the order of Free and ReleaseMutex, and that seemed to do the trick. But it worked only once. On the second run I got the same problem.

Please, help. I'm really stuck now.

[HeDiBo]

When I looked at your implementation of TextHint, I could not understand how the Hint would disappear when the TsEdit has focus.

Then I realized that it was finally a problem in DoTextHint.

I made an obvious modification to the TsEdit component by overriding the DoTextHint procedure and the hint text would show on an empty edit field even if it was focused, as expected.

[HeDiBo]

I looked further into the TextHint implementation of Delphi. And it's plain wrong. Because when the user shifts focus to a TEdit the hint disappears

They made this a deliberate “feature” because Windows does allow a visible hint when the edit has focus. But Delphi decided to ignore this possibility and remove the hint whenever the user shifts focus to the control

However they were gracious enough to make the flawed DoSetTextHint procedure virtual. That would allow for TsEdit to use a general sSkinManager.Options value to show the hint always.

[HeDiBo]

'Support' wrote:

The TextHint property exists in the Delphi 2009 and newer, and supported by AphaSkins.

Do you mean this property?

I thought about another feature, when all edits changes an own looking if some value has been entered there.

I'm an old Delphi 7 programmer. So, I never knew the property already existed. When I looked into it, I found that it is not used in the control that would most benefit from it: the TsDBEdit. That's because it is also missing in it's parent TDBEdit. Any idea why TextHint is a public property in TDBEdit i.s.o. a published property?

Your idea of changing an edit's look when something is entered is nice

[HeDiBo]

'Support' wrote:

I'm agree with you, this feature is useful.

I think, this is must be centrally controlled option, maybe from sSkinManager.Options

What do you think?

I would prefer a new component (TsHintedEdit). WIth settings in SkinManager, every TsEdit would exhibit this behavior. That may not be what you want, because in other parts of your project you may want to use normal hints. Remember a HintedEdit can only contain a very short hint. Such a HintedEdit may have a separate normal hint as well!

Thanks for considering this.

[HeDiBo]

I found out that the origin of the problem is a little bit earlier in the movie. I made a shortened version at exactly the point of error.

[attachment=8499:AbortAnalyzed.rar]

This is the moment just before the problem:

[attachment=8500:ABort 1.jpg]

The currently selected path is displayed at the bottom as C:Program Files(X86)WIP

Then the path is changed:

[attachment=8501:ABort 2.jpg]

That changes the current path to another Volume entirely (T:DICKWIPDelphiInternationalDutch). If you look at the movie you can see some peculiar movement.

Any directory selected after this will give the exception:

[attachment=8502:ABort 3.jpg]

The folder seems not chosen, but when the OK button is clicked, the program happily continues with the chosen folder, without further consequences.

'Support' wrote:

Thank you, I see it.

What is content of this directory? Does exist some “strange” names there?

Maybe, this behavior is depended from the project manifest?

You can try to change the Application options there…

As stated above, it doesn't matter which directory is chosen.

I'm not sure what you mean with the project manifest.

[HeDiBo]

'mol' wrote:

Try this:

https://stackoverflo…-even-on-resize

Thanks for that. It's not ideal but it does hide the scrollbar.

I was looking for some code to disable the painting of the scroll bar altogether. But I'm grateful for your suggestion

[HeDiBo]

'Support' wrote:

Maybe, you can make a video where I can see it in real-time? I hope, I will see something useful.

This is it:

[attachment=8494:ShellTree bug.rar]

Please delete it from my account again. It's very big.

I tried the same thing outside the IDE and got the same bug (that's some sort of relieve I think).

It has to do with the sequence of folders selected.

I also tried it with the test program I made. But using the same folder selections the problem does not occur

[Author]

Posts