|
I'm using the methods in the following url to monitor a samba folder for changed files (the more modern api to do this isn't supported).
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/obtaining_directory_change_notifications.asp
My problem is that when the connection to the remote drive is lost and restored the call always returns WAIT_TIMEOUT even when changes are made.
Is there a work around for this problem?
PS in the unlikely event taht it matters I'm using the signatures on pinvoke.net to call the API from c#, the relevant portion of the code is a direct port from one language to the next.
|
|
|
|
|
I have experienced problems with that function (and ReadDirectoryChangesW(...), as I recently wrote here[^]) when using remote/network shares.
The problem (for me) has been that the SMB implementation on the remote system was broken, or just did not support the ability to report on directory/file changes. I had to modify my file detection threads to have also have a polling ability, so even while waiting for the change notification to fire (using WaitForMultipleObjects(...)), they also used the timeout interval to poll for new files. That way, even if the change notification failed to be created or simply failed to fire, I would not miss any files (it would just take a little longer).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Thank you. Polling will due as a fallback option, and if there's a wide variety of ways smb can blowup seems to be a good idea. I've kludged around most of the other warts I've found with the samba implementation on our test box, my client's using a different flavor of *nix, so if they're inconsistantly broken it's a definate concern.
|
|
|
|
|
dan neely wrote: My problem is that when the connection to the remote drive...
Is this connection via UNC or a drive letter?
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
I'm assuming UNC is this format "\\server\path\file"? IF so yes.
|
|
|
|
|
Then seem if the same thing happens when you use a drive letter instead.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
I don't know that it'd really matter. I've no control over how the client wants to set their system up.
|
|
|
|
|
dan neely wrote:
I don't know that it'd really matter.
I have seen instances where a function acted one way with a UNC path, and another way with a drive letter. I don't see it hurting anything to try just so that you'll know for future reference.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
I'm using a tree control in a dialog box via a CTreeCtrl object, which is attached to the tree in the dialog resource via SubclassDlgItem in the dialog's OnInitDialog handler. I can fill the tree in OnInitDialog, and it displays correctly.
At a later time, if I call the DeleteAllItems() function on the tree and refill it, the tree erases but does not paint the new contents unless I resize it vertically or I minimize and restore the dialog.
This behavior occurs if the TVS_NOSCROLL style is set for the tree. If this style is not set, the tree updates properly.
In this case, having the TVS_NOSCROLL style set was a mistake, so I'm not out anything.
I was just curious; has anyone else seen this, and is there any explanation? I spent an annoying three hours trying to fix this problem, and ended up at the 'OK, let's turn styles on and off' stage of trying to diagnose it  .
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I'm using a tree control in a dialog box via a CTreeCtrl object, which is attached to the tree in the dialog resource via SubclassDlgItem in the dialog's OnInitDialog handler.
Is this necessary (calling SubclassDlgItem())? Why not just add a CTreeCtrl member variable to the dialog? You should then have something like the following in the dialog's DDX routine:
DDX_Control(pDX, IDC_TREE_CONTROL, m_tree_control); I'm not saying this will solve your problem, but it more in line with what MFC is doing elsewhere.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
I tried it both ways, using SubclassDlgItem and DDX_Control and still had the problem. If you look at the MFC source, DDX_Control ends up being a simple call to SubclassDlgItem anyway.
Software Zen: delete this;
|
|
|
|
|
I have found painting-related problems to be easy to find in the new Common controls.
Usually, before any larger operation, such as a complete dump and refill of something like a TreeView Control or a ListView Control, I do the following for both performance and painting/update reasons:
m_tvTree.SetRedraw( FALSE );<br />
m_tvTree.SetRedraw( TRUE );<br />
m_tvTree.RedrawWindow();
That last part, RedrawWindow(...), usually handles any mis-paints that may have occured. I would suggest trying that function after your delete and reinsert steps.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
I tried the RedrawWindow() call as well. It had no effect. I also tried invalidating and RedrawWindow() on the whole dialog, and no joy there either (other than the lovely flash/flicker  ).
What convinces me this is a bug in the control is that resizing the control vertically fixes the painting problem, while resizing the controlling horizontally does not. It appears that the DeleteAllItems() operation fails to set a flag or other value in the control when the TVS_NOSCROLL style it set, that then doesn't get set properly until a window state change or size comes through. This flag is presumably related somehow to the scrolling operation.
Software Zen: delete this;
|
|
|
|
|
I can remember one of the controls having a problem with styles, and I originally thought that was your problem, but I think that's the CTabCtrl.
A search at Google Groups returned this:
Link
I couldn't find anything on the bug at MSDN.
...
And just as a heads up to prevent a possible future headache - there is a bug with the tree control involving checkboxes.
Link
I wasted a few hours on that one in the past.
"My dog worries about the economy. Alpo is up to 99 cents a can. That's almost seven dollars in dog money" - Wacky humour found in a business magazine
-- modified at 13:09 Wednesday 8th February, 2006
|
|
|
|
|
Thanks, Jack. It's nice to know it's something someone else has seen  .
Software Zen: delete this;
|
|
|
|
|
Hello
I am creating a dialog based application using MFC. I want that, by just executing my program, after it draws itself on computer screen, it should automatically start its work (i.e. scanning pc). Till now I have to click a button on dialog after it draws itself on computer screen, to start scanning. Can anyone tell me how can do it?
Waiting for kind responce...
We Believe in Excellence
|
|
|
|
|
|
OnInitDialog() gets called before the dialog is displayed...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Aqueel wrote: I want that, by just executing my program, after it draws itself on computer screen, it should automatically start its work (i.e. scanning pc).
At the end of the OnInitDialog() method, call PostMessage() with a user-defined message. In the handler for that message, start your work.
Instead of a message, you could call AfxBeginThread(). This would allow your UI to remain active while the work was still going on.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Thank you very much. It works...
We Believe in Excellence
|
|
|
|
|
The scenario is this:
In a 16 bit application A.app I am calling a 32 bit dll B.dll with a method exposed "DisplayDialog(HWND hWnd)".
DisplayDialog is called through the following sequence:
hDD = LoadLibraryEx32W(B.dll);
hDisplayDialog = (DISPLAYPPROC)GetProcAddress32W(hDD, "DisplayDialog");
CallProcEx32W(1, 1, hDisplayDialog, hWnd);
The resource for the dialog which I want to diaplay is in a 2nd 32 bit dll
C.dll. I am loading C.dll in B.dll using
hInstance = LoadLibrary(C.dll).
Then to display the dialog I am using this code in B.dll:
hDlg = CreateDialogParam(hInstance, MAKEINTRESOURCE(IDD_SOME_DIALOG), hWnd, (DLGPROC)SomeDlgProc, NULL);
ShowWindow(hDlg , SW_SHOWNORMAL);
SomeDlgProc is defined in B.dll.
hDlg is comming out as NULL.
GetLastError following the function call is returning 0.
But if I call B.dll from a 32 Bit app, it is working fine.
Please advice what is going wrong.
Thanks,
|
|
|
|
|
Hello,
I´ve made a Service Class based in the articles:
-"Creating a Simple Windows NT Service in C++" by Nigel Thompson on the MSDN.
-CNTService v1.06 - NT Service Framework By PJ Naughter
Well, everything was ok until the moment I´ve created this guy:
CFileFind *finder=new CFileFind(); (MFC class ... yes, I built it with MFC, probably a great error). I tried with other objects too and I got the same problem: in the debugger the service seams to stop responding and emiting "life" signals.
Does anyone know if the Service.exe controls the amount of memory for a Service (I suspect thats the problem), or if is there anything that I´m missing?
Thanks,
Dyrl
|
|
|
|
|
So what exactly is the problem:
Compiler error with CFileFind statement
Runtime error when creating CFileFind object
CFileFind object gets created but service stops responding
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Well, it looks like the service stop responding ´cause the last message to the debuger was sent before the CFileFind was created. I put another msg after it´s creation and the msg didn´t came to the debbuger. So, I supose it is the service that stop responding.
|
|
|
|
|
IIRC (and I'm pretty sure I do), using MFC to write services is a big mistake. MFC assumes that you're running on a desktop in several places and there are all kinds of permission problems. The fact that your service just stopped suggests that this is maybe what's happened. If you're running a debug build, MFC throwing an assertion also has this symptom.
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison
Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
