|
You brought up some good points, thanks for the feedback. I didn't have any if statements to test but when it crashed I used a quickwatch on some of the variables. It would create head* but no myList*, I have no idea why. The code is identical for both of them. Maybe I should try GCC just so I can compare the results.
paully
|
|
|
|
|
paully wrote: ...but when it crashed...
Where?
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Hi you all.
I have a thread intensive windows service written in Visual C++ for a communicacions app.
There is a mother thread which launches child threads each of which opens a new connection to Oracle by means of the ODBC Driver.
The child threads are created and die, buy sometimes a big amount of them can be created at the same time (about 200 threads when a massive alert is sent to the remote client apps) which mean that about 200 connections are opened against the driver and last for some time.
My problem is that when this happens some threads are frozen in the Open function of the CDatabase connection.
I tried to write a bit of code to test it (one loop which launched threads which just opened connections to the database and waited in an infinite loop to keep everything opened) and the problem persisted. But as this time it was a desktop app (not a winservice) an Oracle ODBC Driver Connect dialog showed asking for Service Name, User Name and Password.
I tested the same code against a SQLServer driver and the app had no problem in launching all the threads.
So now comes the question ¿is there a limit in oracle's driver for the number of connections per process?
I am using Oracle's Driver version 10.01.00.31, the database is an Oracle 10gR1, and the service is written in Visual C++ (Visual Studio 2003).
The database is not owned by us, so we cannot modify any parameters.
|
|
|
|
|
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,
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
