|
The short answer is probably yes. I'd suggest you look over this[^] article for a start. The artice suggests that the size of the connection pool should be configurable at runtime.
Chris Meech
I am Canadian. [heard in a local bar]
When I want privacy, I'll close the bathroom door. [Stan Shannon]
BAD DAY FOR: Friendly competition, as Ford Motor Co. declared the employee parking lot at its truck plant in Dearborn, Mich., off limits to vehicles built by rival companies. Workers have to drive a Ford to work, or park across the street. [CNNMoney.com]
Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
|
|
|
|
|
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.
|
|
|
|