Intelligent Tree.

[SkyFrontier]

zer0:

Which bug is that? The one with moving junctions into each other on XP and trying to undo?

-the bug I were told was not even existent? Couldn't resist... (really wanted to locate the thread where I reported it, but no time to fight with forum's search... maybe later, for the posterity...
dmin:

I have to correct myself. While this was generally implemented there was a bug that made it dysfunctional for a large amount of cases. Damn it. But now it's fixed!

Thanks, Don! That would help a lot... Have to get a massive backup ready anytime soon, and that will surely help!

[nas8e9]

Good news and bad news: the good news is that XYplorer *does* monitor changes to the tree. The bad news: it only does that for the current folder. That means that any tree changes outside the current folder will only be shown by manually refreshing the tree.

Really??? I think that's old information. At least here the whole tree is monitored and all changes are reflected.

I was basing myself on your post here from januari this year. (Admittedly, an age ago in terms of XYplorer development... )

I have to correct myself. While this was generally implemented there was a bug that made it dysfunctional for a large amount of cases. Damn it. But now it's fixed!

Extremely pleased to hear this. Just to prevent disappointment on my end: does this mean that when changing to a tab displaying a folder in which folders were added/renamed/deleted *by another process*, these changes are already reflected in the tree?

Edited: added "*by another process*".

[admin]

Good news and bad news: the good news is that XYplorer *does* monitor changes to the tree. The bad news: it only does that for the current folder. That means that any tree changes outside the current folder will only be shown by manually refreshing the tree.

Really??? I think that's old information. At least here the whole tree is monitored and all changes are reflected.

I was basing myself on your post here from januari this year. (Admittedly, an age ago in terms of XYplorer development... )

I have to correct myself. While this was generally implemented there was a bug that made it dysfunctional for a large amount of cases. Damn it. But now it's fixed!

Extremely pleased to hear this. Just to prevent disappointment on my end: does this mean that when changing to a tab displaying a folder in which folders were added/renamed/deleted, these changes are already reflected in the tree?

Try it, there are so many cases...

Somebody might ask, what's the problem, you get a change notification and refresh the whole tree and you're done. Yeah, this is the highway to a flickery tree like in Explorer, which does a complete refresh on every breath you take. No, refreshing the tree gets interesting and surprisingly complex when you want to do with optimal performance and minimal flicker. That's my passion (ok, one of my passions ) so it takes a little to make it work perfectly for every use case.

[SkyFrontier]

Admin:

v9.30.0016 - 2010-07-26 19:52
! Tree: Improved the automatic refresh of the Tree pane for non-
current folders. Now all nodes (incl. special paths) should be
updated correctly, directly and smoothly, including all folder
related data like highlights, tags, favorites, thumbnail caches
etc. -- even if those nodes are not shown currently in the tree!
As long as XY is running then every change to the file system by
any other app should be auto-adjusted to in XYplorer's various
path related data. That's the goal and we are quite near.

That's it. Problem solved. As far as it concerns to .htm(L) files. Later I will try to reproduce the bug on other systems/apps with older versions against this beta, but it's there: FOLDER created by another app, tree synced, .htm(L) file showed right on time by XY. Faster and smoother than PDesk, as it seems. A HUGE thank you, Don. Again.

[nas8e9]

Not sure it's working as intended yet:
1. open at least two tabs;
2. the first tab points in my case to C:\Temp; the second tab points to D:\Data (basically, somewhere far away from the first folder tree-wise);
3. switch to the second tab;
4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;
5. switch back to the first tab.

Expected result: the newly created Test folder is shown in the tree.

Actual result: it isn't.

Was I expecting too much ?

XYplorer 9.30.0016 / Windows 7 x64.

[SkyFrontier]

As a side note: old (BUGGED! lol) version sometimes tells the .htm file is there, being a zero-size file despite it's completed and showed like that by (happily!) both PDesk and XY latest beta.

[admin]

4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;

The folder should already be shown in the tree after that line! What other program is this? Maybe it does not notify the system?

[admin]

BTW, I just saw some minor glitches here with regard to special folders (maybe zer0's bug is finally fixed... ) .. working on it.

Which bug is that? The one with moving junctions into each other on XP and trying to undo? As I have now running Win 7 on both laptop and desktop, this is no longer an issue (for me).

Some bug with auto-refresh of special folders, don't remember exactly...

[nas8e9]

4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;

The folder should already be shown in the tree after that line! What other program is this? Maybe it does not notify the system?

It does indeed vary by program:
- Directory Opus as well as the command prompt: fail;
- Windows Explorer: success.

My initial test was with the command prompt. I've yet to test the program whose folder output was the reason for my request in the other thread. I really hope that it notifies the system, but if I understand correctly XYplorer is currently dependant on other programs creating folders, to do *two* things:
1. create the folder (duh...);
2. notify the system?

I'd expect and hope that *Windows* - when it gets an API request to create a folder - rather than the calling application, would post a message?

[admin]

4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;

The folder should already be shown in the tree after that line! What other program is this? Maybe it does not notify the system?

It does indeed vary by program:
- Directory Opus as well as the command prompt: fail;
- Windows Explorer: success.

My initial test was with the command prompt. I've yet to test the program whose folder output was the reason for my request in the other thread. I really hope that it notifies the system, but if I understand correctly XYplorer is currently dependant on other programs creating folders, to do *two* things:
1. create the folder (duh...);
2. notify the system?

I'd expect and hope that *Windows* - when it gets an API request to create a folder - rather than the calling application, would post a message?

I'd expect and hope the same! (Because XY does not do any notification neither.) It might depend on the API you use...

... little testing...

arghh, XYplorer is among the group that does not trigger any refresh in another XYplorer instance. Only when it deletes to recycler. So it's the shell commands that have the notification built in. But not the Kernel API. I know what I have to do tomorrow....

[SkyFrontier]

Did your experiment here, nas8e9. Used PDesk to create a new folder. Worked as expected (XY showed newly crated folder).

Edit: admin:

...arghh, XYplorer is among the group that does not trigger any refresh in another XYplorer instance.

- beta .30.0009 produced a folder successfully displayed by .0016.

[nas8e9]

4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;

The folder should already be shown in the tree after that line! What other program is this? Maybe it does not notify the system?

It does indeed vary by program:
- Directory Opus as well as the command prompt: fail;
- Windows Explorer: success.

My initial test was with the command prompt. I've yet to test the program whose folder output was the reason for my request in the other thread. I really hope that it notifies the system, but if I understand correctly XYplorer is currently dependant on other programs creating folders, to do *two* things:
1. create the folder (duh...);
2. notify the system?

I'd expect and hope that *Windows* - when it gets an API request to create a folder - rather than the calling application, would post a message?

I'd expect and hope the same! (Because XY does not do any notification neither.) It might depend on the API you use...

... little testing...

arghh, XYplorer is among the group that does not trigger any refresh in another XYplorer instance. Only when it deletes to recycler. So it's the shell commands that have the notification built in. But not the Kernel API. I know what I have to do tomorrow....

Not fixed in 9.30.0019 yet, I'm afraid.

Test used:

1. Open at least two tabs;
2. the first tab points in my case to C:\Temp; the second tab points to D:\Data (basically, somewhere far away from the first folder tree-wise);
3. switch to the second tab;
4. use another program to create a folder in the first folder, e.g. C:\Temp\Test;
5. switch back to the first tab.

Expected result: the newly created Test folder is shown in the tree.

Actual result: it isn't.

[admin]

No, what I fixed is my part: XY now notifies other apps (via shell).
I cannot fix other apps that do not notify XY (via shell).

[nas8e9]

No, what I fixed is my part: XY now notifies other apps (via shell).
I cannot fix other apps that do not notify XY (via shell).

Sorry for the misunderstanding. If I have understood you correctly so far, there are two API's that can be used to create a folder:
- Windows Shell API;
- kernel API.

When applications use the former, the Windows Shell API takes care of the notification. When applications use the kernel API however, the kernel does *not* provide a notification; it leaves that up to the application that called its API.

Also, XYplorer (to keep performant) only watches the tree by listening to notifications; it does not monitor all file/folder activity because performance would tank.

Combining the two things above, for XYplorer to display tree modifications by other applications effectively, that other application must either use the Windows Shell API *or* post a notification about what it got the kernel API to do. If it doesn't do either (the command prompt and Directory Opus are two that seem to use the kernel API without posting notifications), XYplorer is unable to automatically pick up their tree actions and therefore doesn't reflect them in its tree.

That's the situation?

[admin]

No, what I fixed is my part: XY now notifies other apps (via shell).
I cannot fix other apps that do not notify XY (via shell).

Sorry for the misunderstanding. If I have understood you correctly so far, there are two API's that can be used to create a folder:
- Windows Shell API;
- kernel API.

When applications use the former, the Windows Shell API takes care of the notification. When applications use the kernel API however, the kernel does *not* provide a notification; it leaves that up to the application that called its API.

Also, XYplorer (to keep performant) only watches the tree by listening to notifications; it does not monitor all file/folder activity because performance would tank.

Combining the two things above, for XYplorer to display tree modifications by other applications effectively, that other application must either use the Windows Shell API *or* post a notification about what it got the kernel API to do. If it doesn't do either (the command prompt and Directory Opus are two that seem to use the kernel API without posting notifications), XYplorer is unable to automatically pick up their tree actions and therefore doesn't reflect them in its tree.

That's the situation?

Exactly!

Only that today I found out that CreateDirectory (a Kernel function) does notify. I just have to take this as another Windows oddity. But mkdir does not.