|
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.
|
|
|
|
|
Hello Mr. Muraoka,
Is there any way to bypass these permitions problems? ´cause I´d like to use several functions from the MFC library, like those for support to UNICODE.
Thanks for your reply.;)
|
|
|
|
|
It's a long time since I looked at this but just Google for MFC and service. The problem is that MFC is pretty monolithic so if you use just a bit of it, you get all of it and you have no control over what a lot of it is doing. If you just need to handle Unicode strings, it's not that hard to do it yourself[^]
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.
|
|
|
|
|
Taka Muraoka wrote: IIRC (and I'm pretty sure I do), using MFC to write services is a big mistake.
Which implies what exactly, that it can't be done or that it shouldn't be done? Several successful examples exist on the Internet, such as this one.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Hmm, I had actually seen that before but forgotten about it Simply writing a NT Service framework in MFC is probably no hassle, it's all the rest of the stuff you need your app to do that will be the problem.
It's many years since we got bitten on the ass by this one but I definitely remember doing a lot of reasearch into it and finding out that using MFC for a service was a Bad Move. There are certain areas in MFC that assumed you were running in a desktop and it would barf if you weren't i.e. running as a service. If you just want to use CString you can get away with it but we used MFC fairly extensively in our app and it just didn't want to work.
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
