[HeDiBo]

'JasonToms' wrote:

By the way, why must we design to modify the source file, is not it better to design a property of skinmanager?

I totally agree. Not every change is a good change (for some). With drastic visual changes like this, the default should be to maintain the looks it had. It must be a skinmanager setting, not a compiled setting.

[HeDiBo]

'Support' wrote:

Hello!

OnChanging is a standard event which occurs before switching of pages and allows to cancel this switching.

The OnPageChanging event has been added in the package with additional “NewPage” parameter. So, developer can check a new tab and decide – cancel changing to this page or allow it.

I see, thank you Serge.

OnPageChange is a very nice addition to the pagecontrol.

So now there are two possible ways to prevent a tab from being changed:

• If you do not want a user to leave the current page, use OnChanging (for instance if the user has to complete some info on the current page).
• If you do not want a user to go to a certain page, use OnPageChanging (for instance if the attempted new page depends on info that's not completed yet).

A third observation I made in this exercise: if you want the appearance of a page to be adjusted when changing page to it, use the OnChange event. The OnChanging and OnPageChanging events come to early for that and may result in unwanted side effects.

Thanks

[HeDiBo]

'Support' wrote:

Hello! Thank you for information.

Hi Serge,

I do not know very well, why OnChange and OnChanging need a third event OnPageChanging.

What does this event bring that the others cannot? Please, explain.

[HeDiBo]

I found the cause of this problem.

I change the appearance of the page upon the OnPageChanging event. That apparently is a no-no. Changing the page layout or anything like that is to be postponed until the OnChange event. By implementing it this way, the problem was solved.

However, as the docs state: “The event (OnChange) is not called if you change the active page in code, for example, by setting the value of ActivePage”. So that's a catch-22 then. The only way to solve this is to call the OnChange event in code when the ActivePage is changed in code. What a stupid implementation of Delphi.

[HeDiBo]

I've made a message trace (with Application.OnMessage) which comes up with some strange messages if the page refuses to turn:

[attachment=8643:PageChangeBug.pdf]

The trace is made with CodeSite. I have eliminated the WM_MOUSEMOVE, WM_NCMOUSEMOVE, WM_MOUSELEAVE and WM_TIMER messages.

Whenever the OnChanging event occurs, the message “Start Tracing” is logged, followed by the message “**** OnChanging ****”.

Whenever the OnChange event occurs, the message “*** OnChange event ***” is logged followed by the message “”**** Trace Stopped *****”.

As you can see, in the first two case, the OnChange event does not occur. But we have the strange messages 1848 and 96. And these messages do not occur if the page is correctly changed!

I don't know what these messages are. Do you recognize them?

[HeDiBo]

'Support' wrote:

Hello

You trying to change active page by mouse or keyboard in this case?

Or by code like “ActivePage := …” ?

As I Said: “he has to click the Tab twice” that's with the mouse of course.

[HeDiBo]

'Lasse' wrote:

I installed v13.00 beta and still get the AV (see attachment).

Could the problem be in TMySkinManager? Can you disclose what this component does?

[HeDiBo]

'Support' wrote:

Sorry. Try this one.

Nice

[HeDiBo]

'Support' wrote:

Hello!

Try this attached file, some changes were added there

Thanks.

Couldn't compile it, the function IsDefaultFont appears not to be present. Also the message constant AC_FONTSCHANGED is not defined.

[HeDiBo]

'Support' wrote:

Hello

Try the new attached file, plz.

Nice changes

One observation:

If I create a new folder with MakeNewFolderEx the TreeView does not (always) reflect that:

In this situation I click “Add Folder” which results in MakeNewFolderEx('New Folder').

Before click:

[attachment=8626:ShellBeforeCreateFoilder.jpg]

After click:

[attachment=8627:ShellAfterCreateFoilder.jpg]

The TreeView does not reflect the change. AutoRefresh and AutoExpand of the TreeView are both True. I think not only should TreeView show the change, it should also select the newly created folder.

[HeDiBo]

The CanEdit procedure needs a bit more. Apparantly the Item parameter can be nil. This happens on a rename of a folder upon a right click with property AutoContextMenus set to true. This is the augmented function:

Code:

function TacCustomShellListView.CanEdit(Item: TListItem): Boolean;
begin
Result := True;
if Item = nil then Exit;
if Item.Index >= Items.Count then begin
Result := False;
Exit;
end{if};
if Assigned(FOnEditing) then FOnEditing(Self, Item, Result);
end;

But as mentioned above, renaming the folder leads to an endless loop.

[HeDiBo]

The bug of not calling the OnEditing event is also present in the standard ShellCtrls.pas file

[HeDiBo]

After making the necessary changes (the loop I could not fix) there's still a significant problem. The directory just made does not become the current directory in the buddy TreeView. Most of the times, the new directory isn't present in the TreeView. Only closing the whole form and reopening it will show the created folder in the TreeView.

[HeDiBo]

'Support' wrote:

Hello!

Try this new file plz.

The OnEditing event of the TsShellListView is never called, because of the mistake I described in the previous post (OnEditing of the parent is not set, because it is a different event). By implementing my little change, that problem is solved.

This piece of code is wrong:

Code:

Selected := nil;
for i := 0 to Items.Count – 1 do
if Folders.PathName = DispName then begin
Selected := Items;
Break;
end;

The DispName is the simple folder name, where PathName is the full path. I think this is better:

Code:

Selected := nil;
for i := 0 to Items.Count – 1 do
if Folders.PathName = NewDir then begin
Selected := Items;
Break;
end;

When this change is applied, you are able to edit the folder name. But after entering the name, the program enters an endless loop, having to do with threads I think (I'm looping in something called ntdll.LdrInitializeThunk).

So, this is not a very good version, I'm afraid.

[HeDiBo]

'Support' wrote:

Try this new patched file, please.

It works fantastic

[HeDiBo]

One of the problems with the exception, is the call to CanEdit here:

Code:

if CanEdit(Selected) then
Selected.EditCaption;

The call to CanEdit goes to the parent TCustomListView which is wrong here. What you need is this:

Code:

portected
function CanEdit(Item: TListItem): Boolean; override;
.
.
function TacCustomShellListView.CanEdit(Item: TListItem): Boolean;
begin
Result := True;
if Assigned(FOnEditing) then FOnEditing(Self, Item, Result);
end;

That brings the OnEditing event of sShellListView into play.

The exception occurred because the MakeNewFolderEx was called with the wrong parameter (the full path in stead of the single foldername). That could be checked in the intro to the call by analyzing the passed folder name.

When these things are corrected, the EditCaption call should be analyzed. As it is, it doesn't work (the selected new foldername flashes but entry of a new name is not possible).

[HeDiBo]

'Support' wrote:

The Enabled property will be added there in the nearest release.

Thank you

[HeDiBo]

'Support' wrote:

I will rewrite a receiving of icons procedure in the nearest release and I hope it helps.

That would be great!

[HeDiBo]

'Support' wrote:

Something wrong with files in the demo, can you check it please?

Very sorry about that

Here's the correct one: [attachment=8620:acShellBug.zip]

[HeDiBo]

'Support' wrote:

Thank you for files

I have tried to implement a hiding of standard scrolls, try the attached file, plz.

Thanks Serge

It works like a charm, except for one problem:

If the web window is resized, making it smaller and making the AC scroll bar appear, there is no redrawing of the web page, and that causes a text clipping:

[attachment=8617:WebPage Unclipped.jpg]

goes to:

[attachment=8618:WebPage Cllipped.jpg]

Look at the upper right: text falls off the window.

The other way around (going from a scrolled window to a full one) the page is redrawn correctly. So it is probably a simple oversight.

[Author]

Posts