PS: I got tired writing this... 
You'll probably get tired understanding everything again! 
Sorry, you don't need to read now. Make yourself comfortable! 
Perfect words!!! I just couldn't speak that simple!!
Well, you've gone a bit far than I thought for this approuch.
I was thinking about a simple extern txt file to this "path list".
But storing this "path list" directly into database registers was very interesting!
Anyway, that is not an efficient solution for this kind of problem, as you've already noticed.
Even though, I liked your "path list" idea inside Tabbles database!
But let me change it: Put this entire path list in a separate table!
i.e: This would be a single register in this new table.
[tbPathChange]idPathChange=1
sourcePathChange="C:\foo1.pdf"
destinyPathChange="D:\foo2.pdf"
timePathChange="11/04/2010 17:00"
Now, we have to consider that this problem barely happens frequently.
That's why I've suggested such complex and process-consuming solution.
Since it wouldn't happen frequently, the "standby" memory and process costs of this solution must be minimal.
So, in my original idea, this "thread", like you said, would be periodical (let's say twice a week?) and since it would be an EXTERN txt file (or a new table like in the example above) it wouldn't be necessary to check EVERY TAGGED FILE from Tabbles database, but ONLY this txt log file (or all the FEW entries in this SMALL new table). Remember that these entries would be checked and DELETED twice a week.
I guess this periodical "thread" wouldn't be that hard, especially in this so rare case: Probably in 90% of the times this "thread" executes, it would find NOTHING inside the log to process.
And please note that all of this process about
"the file is in one of these paths, I don't know exactly which one until I check the disk" WOULD HAPPEN ONLY IF the original path inside Tabbles database is not found during user access. Again, probably in 90% of the times an user access a file through Tabbles, the file path would be OK, accessed, executed, and NO ADDITIONAL PROCESS would happen about this "crazy" solution. UNLESS, of course, Tabbles finds out that the requested file is missing. THEN, in this very moment, finally, all of this process to discover where the file is would come up!
Ok, let's see this in practice:
Maybe you have a code like this to open a file: (in C#)
//imagine the content of filepath is "C:\foo1.pdf"private void OpenFile(string filepath)
{
.//This method returns True if the file exists.if (System.IO.File.Exists(filepath)==true)
.{
..//this executes the file in a given path..System.Diagnostics.Process.Start(filepath);
.}
.else
.{
..//Displays a "file missing" message to the user...System.Windows.Forms.MessageBox.ShowDialog( "The requested file is missing." );
.}
}
Now, all you have to add to this code is just encapsulate this MessageBox with a simple IF that calls my solution method (which, by the way, can be from an extern DLL or from an intern class). I'm gonna exemplify:
//imagine the content of filepath variable is "C:\foo1.pdf"private void OpenFile(string filepath)
{
.If (System.IO.File.Exists(filepath)==true)
.{
..System.Diagnostics.Process.Start(filepath);
.}
.else
.{
.
.//This method would be a calling to my solution, that wouuld search for a new path inside log
..//It would return the new path of the file, which was stored in log, and could be "D:\foo2.pdf"
..//If no path is found inside the log, then it may return an empty string or message...string newPath = SearchNewPathInsideLog( filepath );
..If ( System.IO.File.Exists(newPath)==true )
..{
...System.Diagnostics.Process.Start(newPath);
..}
..else
..{...System.Windows.Forms.MessageBox.ShowDialog( "The requested file is missing." );
..}.}
}
So, if the original filepath is NOT missing, no additional operation happen!
You may, of course, modify it to be more "professional" and less redundant.
I was going to clarify a bit more, but I guess maybe this is enough for now.
What errors have you found in this "trimming" operation?
Probably you really need to filter by "timePathChange" (see above) before "trimming" it.
It would filter all new entries to check/delete only those that have already expired.
That would avoid losses if the "trimming" is called right after a move operation.
How does it seem to you?
Do you think many files would be moved by explorer?
And if so, do you think this algo would be very consuming?
I'm gonna say again that I would be happy in helping with the development of this class/code!
Maurizio wrote:Changing topic, I was hoping for a different approach, namely to detect (via injection) that this dialog (
http://gyazo.com/1bd7636c70770ce2afe29b03a05a5993.png) appeared, and that a specific button of this dialog has been pressed. AFAIK, this should be possible via sniffing the window handles. But I might be mistaken.
Well, if you know the name of this window/function, then we would try to inject it
I guess you'll have to ask this question to Sujay, 'cause maybe he knows it.
But if you want my opinion, why would Microsoft make an API for this window?
I mean, it's not supposed to be called/accessed by an application.
The move operation is called by anyone, but this box might be called directly by system.
And one more thing: In my Windows XP there's no such window, at least with this options.
There's only 2 buttons: Replace or cancel. What's the technical difference between them?
Anyway, I'm sure I know less than you. And nothing is impossible in cyberspace... hehehe
If you tell me more about "sniffing the window handlers" maybe I can discover something.
Good luck! See'ya!
by Leandro » Fri Jul 30, 2010 10:48 pm 
