C / C++ / MFC

Jose Lamas Rios21-Aug-05 19:05

21-Aug-05 19:05

Sorry, I didn't understand this part:

Nishad S wrote:
it will get hanged on activate or deactivate other windows which make my program to do repaint

Can you clarify it?

--
jlr
http://jlamas.blogspot.com/[^]

Nishad S21-Aug-05 19:19

Nishad S

21-Aug-05 19:19

Suppose my program is running top of all windows, when I minimized and then restore any other window over my program's window, then my program will get hanged.

I think it causes the complete redraw of my program's window.

It is also get hanged when I activate another window over my window completely and then reactivate my window.

In short, I think, my program gets hanged when the window is completely redrawn.

If there is no controls on the page, no problem!

Nishad S21-Aug-05 19:39

Nishad S

21-Aug-05 19:39

I found the following...

When I create the propertysheet by DoModal() there is no problem!

Also the following code is also fine:

m_pPropSheet = new CPropSheetEx("");

m_pPropSheet->AddPage(&m_page3);
m_pPropSheet->AddPage(&m_page2);
m_pPropSheet->AddPage(&m_page1);

m_pPropSheet->Create();

But the propertysheet comes in a new window, which I cannot allow!

Steve Mayfield21-Aug-05 20:00

Steve Mayfield

21-Aug-05 20:00

all the problems I have had with hanging Property Sheets has been due to this[^]

Steve

Nishad S21-Aug-05 20:09

Nishad S

21-Aug-05 20:09

Thank you!

I tried, but the problem is still exists.

Jose Lamas Rios22-Aug-05 3:06

22-Aug-05 3:06

I'm just guessing here, but try adding clipping styles to the sheet window:

m_pPropSheet->Create(this, WS_CHILD | WS_VISIBLE | WS_CLIPCHILDREN | WS_CLIPSIBLINGS);

Also, you might temporarily comment the tab control subclassing so as to determine if the problem is related to the tab control or not.

--
jlr
http://jlamas.blogspot.com/[^]

VS2005 linking errors.

Christian Graus21-Aug-05 17:57

Christian Graus

21-Aug-05 17:57

I have a VC6 project I am moving to VS2005 ( I did not write it ). I've just finished all the compile errors, but the link errors have me beat. I moved a lot of code from nonstandard headers to headers like iostream, fstream and string. I've put using statements in, obviously.

I'm getting a ton of these:

Error 58 error LNK2001: unresolved external symbol __imp_??6std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z dcmjpeg.lib

It's very possible that these errors are from linking against other libraries, which may also use the old headers.

It's a long time since I've been this involved in a C++ project, and I have to say that while most of it has come back easily, on this I'm stumped. Any advice appreciated.

Christian Graus - Microsoft MVP - C++

Jose Lamas Rios21-Aug-05 18:35

21-Aug-05 18:35

Not an answer, but some time questions still help Smile | :)

The error mentions dcmjpeg.lib (part of the DICOM Toolkit, I guess.) Do all of the errors come from dcmtk libraries?

Are you compiling those libraries from the sources or using distributed binaries? If the former, are you sure they are being compiled with the same settings as the rest of your project? If the latter, maybe you need a newer version?

You might get something at comp.protocols.dicom...

--
jlr
http://jlamas.blogspot.com/[^]

Christian Graus21-Aug-05 18:41

Christian Graus

21-Aug-05 18:41

Thanks - I just worked out that some of my libraries were from the DICOM stuff, and went looking for a newer version. No, I'm not building the library. I just inherited this project in the last few weeks, and my first recommendation was a move to a newer compiler than VC6, which forced fixing all the non standard C++ in the project ( methods with implied int/no return statements, base classes with pure virtual methods that were not implimented in all derived classes, etc ).

Christian Graus - Microsoft MVP - C++

Jose Lamas Rios21-Aug-05 18:51

21-Aug-05 18:51

Christian Graus wrote:
I just inherited this project [...] methods with implied int/no return statements

I hope whoever wrote those methods isn't at the reach of your hands Smile | :)

Christian Graus wrote:
base classes with pure virtual methods that were not implimented in all derived classes

But these couldn't be instantiated even in VC6, right?

--
jlr
http://jlamas.blogspot.com/[^]

Not able to Call one COM Dll inside ATL Service

Christian Graus21-Aug-05 19:17

Christian Graus

21-Aug-05 19:17

Jose Lamas Rios wrote:
I hope whoever wrote those methods isn't at the reach of your hands

LOL - actually, I started in that frame of mind, but he's a vet who learned C in uni 10 years ago, and ended up on this project. He's pretty open to learning how to do things properly, and he's a nice guy. I think he may have been the wrong guy for the job, but it's too late to change that now.

Jose Lamas Rios wrote:
But these couldn't be instantiated even in VC6, right?

Imagine my disgust, but I'm afraid VC6 was compiling this code.

FWIW, I got the latest library, and it's clear it's been updated. The old version contains a file called ofstream.h (!). It includes pretty much every non standard header I can think of, and seems to me to add to the original ofstream.h. I can't imagine why else it's there, and it certainly has comments to say people have been adding to it. Bloody hell.

I never seem to charge enough for this sort of work....

Christian Graus - Microsoft MVP - C++

Prasannajit Dash21-Aug-05 17:53

Prasannajit Dash

21-Aug-05 17:53

Hi,

I am Prasannajit Dash,created one NT Service in ATL Wizard and also created
another COM Dll through ATL. I tried to call the COM Dll before the _Module.Start function in the _tWinMain() function of the Service. I could not able to see the CoCreateInstance() gets succeeded. I do not know what could be the reason behind the call so that I am not able to get the interface pointer back.

Re: Not able to Call one COM Dll inside ATL Service

Jose Lamas Rios21-Aug-05 18:12

Re: Not able to Call one COM Dll inside ATL Service

21-Aug-05 18:12

What's the result of CoCreateInstance?

Are you calling CoInitialize before CoCreateInstance?

--
jlr
http://jlamas.blogspot.com/[^]

Anonymous21-Aug-05 18:28

Anonymous

21-Aug-05 18:28

Yes, I am calling CoInitialize(NULL) before CoCreateInstance() API.
hr = CoCreateInstance() retunrs -2147024809, not 0.This is what I am replying
to you. Please help me how to handle this problem.

Re: Not able to Call one COM Dll inside ATL Service

Jose Lamas Rios21-Aug-05 18:40

Re: Not able to Call one COM Dll inside ATL Service

21-Aug-05 18:40

-2147024809 == 0x80070057 == E_INVALIDARG == Invalid Argument.

Post some code to see how you are calling CoCreateInstance.

--
jlr
http://jlamas.blogspot.com/[^]

Prasannajit Dash21-Aug-05 19:16

Prasannajit Dash

21-Aug-05 19:16

#include "..\\NTServiceDLLOne\\NTServiceDLLOne.h" //Headers for IDllNtServiceCOM
#include "..\\NTServiceDLLOne\\NTServiceDLLOne_i.c" //For CLSID_and IID

CoInitialize(NULL);//Initialize COM Library
IDllNtServiceCOM* ppInterface = NULL; //COM Dll Interface Pointer
HRESULT hr = CoCreateInstance(CLSID_DllNtServiceCOM, NULL, CLSCTX_INPROC_SERVER, IID_IDllNtServiceCOM, (LPVOID*)ppInterface);
BSTR bstring = L"Hello World";
LPUNKNOWN punk = NULL;
hr = ppInterface->ShowMessageBox(bstring, &punk); //
hr = ppInterface->Release(); //Releasing interface pointer
CoUninitialize(); //Uninitialize COM Library

_Module.Start();

Re: Not able to Call one COM Dll inside ATL Service

Jose Lamas Rios22-Aug-05 5:43

Don't want to inherit Parent's process space

22-Aug-05 5:43

ppInterface is an interface pointer. You need to pass a pointer to the pointer so that CoCreateInstance can load a value in it.

Instead of:

IDllNtServiceCOM* ppInterface = NULL; //COM Dll Interface Pointer
HRESULT hr = CoCreateInstance(CLSID_DllNtServiceCOM, NULL,
                 CLSCTX_INPROC_SERVER, IID_IDllNtServiceCOM, (LPVOID*)ppInterface);

It should be:

IDllNtServiceCOM* pInterface = NULL; //COM Dll Interface Pointer
HRESULT hr = CoCreateInstance(CLSID_DllNtServiceCOM, NULL,
                 CLSCTX_INPROC_SERVER, IID_IDllNtServiceCOM, (LPVOID*)&pInterface);
if (SUCCEEDED(hr))
{
   // Use pInterface
}

--
jlr
http://jlamas.blogspot.com/[^]

Tony Valiantis21-Aug-05 17:51

Tony Valiantis

21-Aug-05 17:51

Hi all,

I have a quick question which I hope someone can help me solve easily. I have a legacy system to maintain which combines WinBatch (a windows scripting language) and Visual C++ 6 applications.

We have a WinBatch script which starts up our Visual C++ appliactions. These apps then create global sections of memory, mutex objects etc. The app then later kicks off another WinBatch script. Seems pretty simple...

The problem we are facing is that the script that is kicked off by the application inherits the process space of the parent application that called it. i.e. it has in its address space handles to the global sections of memory etc that belong to the parent etc. This causes us some grief later down the track.

My question is that is there a way to spawn off a sub process in VC++ 6 that does not inherit from the parent? The system was originally coded using the win32api system call, and I have also tried the _spawnl call, but to no effect.

Hopefully I have just missed something really obvious here.

Many thanks,

Tony.

Re: Don't want to inherit Parent's process space

Jose Lamas Rios21-Aug-05 17:58

Re: Don't want to inherit Parent's process space

21-Aug-05 17:58

Would CreateProcess help? It receives a BOOL bInheritHandles parameter.

--
jlr
http://jlamas.blogspot.com/[^]

Tony Valiantis21-Aug-05 18:27

Tony Valiantis

21-Aug-05 18:27

Have you ever had one of those moments where you slap yourself in the head an say
"Of course...DOH!!!"

Thank you very much. Your suggestion worked a treat.

Cheers,
Tony.

Re: Don't want to inherit Parent's process space

Jose Lamas Rios21-Aug-05 18:43

VC++ MFC Linking error (LNK 2001, 2019) in VS .NET 2003

21-Aug-05 18:43

Tony Valiantis wrote:
Have you ever had one of those moments where you slap yourself in the head an say
"Of course...DOH!!!"

You mean that could be the cause of my permanent headache? Of course... DOH!!! Smile | :)

Glad to be of help.

--
jlr
http://jlamas.blogspot.com/[^]

FFKONG21-Aug-05 17:22

FFKONG

21-Aug-05 17:22

I developed a Visual C++ (MFC) with MS Visual Studio .NET 2003, but encountered the following linking errors when compiling for realease build. However, it was compiled successfully in debug configuration.

mfcs71.lib(stdafx.obj) : error LNK2001: unresolved external symbol ___security_cookie
atls.lib(atlbase.obj) : error LNK2001: unresolved external symbol ___security_cookie
ConnectSock.obj : error LNK2019: unresolved external symbol ___security_cookie referenced in function "unsigned int __stdcall ATL::_AtlGetThreadACPFake(void)" (?_AtlGetThreadACPFake@ATL@@YGIXZ)
DBOperation.obj : error LNK2001: unresolved external symbol ___security_cookie
MainFrm.obj : error LNK2001: unresolved external symbol ___security_cookie
stdafx.obj : error LNK2001: unresolved external symbol ___security_cookie
mfcs71.lib(stdafx.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
atls.lib(atlbase.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
ConnectSock.obj : error LNK2019: unresolved external symbol @__security_check_cookie@4 referenced in function "unsigned int __stdcall ATL::_AtlGetThreadACPFake(void)" (?_AtlGetThreadACPFake@ATL@@YGIXZ)
DBOperation.obj : error LNK2001: unresolved external symbol @__security_check_cookie@4
MainFrm.obj : error LNK2001: unresolved external symbol @__security_check_cookie@4
stdafx.obj : error LNK2001: unresolved external symbol @__security_check_cookie@4
stdafx.obj : error LNK2019: unresolved external symbol __imp___resetstkoflw referenced in function "bool __cdecl ATL::_ATL_SAFE_ALLOCA_IMPL::_AtlVerifyStackAvailable(unsigned long)" (?_AtlVerifyStackAvailable@_ATL_SAFE_ALLOCA_IMPL@ATL@@YA_NK@Z)
mfcs71.lib(stdafx.obj) : error LNK2001: unresolved external symbol __imp___resetstkoflw
mfcs71.lib(stdafx.obj) : error LNK2019: unresolved external symbol __SEH_epilog referenced in function "bool __cdecl ATL::_ATL_SAFE_ALLOCA_IMPL::_AtlVerifyStackAvailable(unsigned long)" (?_AtlVerifyStackAvailable@_ATL_SAFE_ALLOCA_IMPL@ATL@@YA_NK@Z)
atls.lib(atlbase.obj) : error LNK2001: unresolved external symbol __SEH_epilog
mfcs71.lib(stdafx.obj) : error LNK2019: unresolved external symbol __SEH_prolog referenced in function "bool __cdecl ATL::_ATL_SAFE_ALLOCA_IMPL::_AtlVerifyStackAvailable(unsigned long)" (?_AtlVerifyStackAvailable@_ATL_SAFE_ALLOCA_IMPL@ATL@@YA_NK@Z)
atls.lib(atlbase.obj) : error LNK2001: unresolved external symbol __SEH_prolog

I have tried to manipulate some of the linking properties for the release configuration but still could not get it working. Could someone help me out on this? Thank you very much.

Re: VC++ MFC Linking error (LNK 2001, 2019) in VS .NET 2003

Jose Lamas Rios21-Aug-05 17:50