If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: How to call Dialog window (formed as resource) from a .DLL

Thanks Igor,

The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.

When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL. But Ok, I'll try your proposition concerning InitInstance.

as the latter blocks thread normal execution while DllMain must never be blocked.

Beside the dubugging issue, should I reject "DoModal approach" in favour of one, based on Create function ?

Re: How to call Dialog window (formed as resource) from a .DLL

Originally Posted by Pavel_47

Thanks Igor,

When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL.

That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded.

You need a complete understanding of how your program works. Otherwise, you will never be able to debug it.

Re: How to call Dialog window (formed as resource) from a .DLL

The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.

That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.

Igor, Paul you had reason - the process I attached to, is not that, which calls my .DLL. Please see below

There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?

Re: How to call Dialog window (formed as resource) from a .DLL

There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?

During this stepping I've just controlled dwReason parameter (that was equal to 1 (means DLL_PROCESS_ATTACH, what seeems to be correct)) and also hDllHandle, which wasn't NULL. The retcode from DllMain was 1.

As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design. During restart there is also break in the .DLL. Here is VS2010 output window content between 2 breaks:

As you can see there is memory leak issue. After second break I didn't step through code - merely clicked on Continue. At the end the Dialog Window appeared, but after some short time (about 2...3 min) the CAD window and Debug Window crashed.

Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?

Re: How to call Dialog window (formed as resource) from a .DLL

Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?

First, no one can solve memory leaks without the entire code and running it.

Second, you should be checking the return code of those functions you're calling, instead of assuming that they work. You say the window isn't displayed, so where is your check for the return value of pDlg->Create() and other functions?

Re: How to call Dialog window (formed as resource) from a .DLL

As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design.

And as I already mentioned before you should find out the reason why your first launch fails. Your first suspect is pDlg->Create. Please debug it through.

And do us a great favor, please stop sending us your screenshots, and get to real investigation on your side. When you find something suspicious, first try finding relevant info with Google and MSDN. Then try to ask your team. I don't believe that CG is your only source of knowledge. But if it is, please ask questions specific to your current problem(s). When you are asked to provide a code, the code should be a project, concise and compilable. It must not be your full project you are working on. Instead it must be a demo that specifically focuses on your problem. Please take this point very seriously.

I suggested you to launch your DLL in a simple C++ client to eliminate effects from CAD. Well, did you?

Re: How to call Dialog window (formed as resource) from a .DLL

Originally Posted by Pavel_47

Here they are:

As Igor mentioned, how do you know your code even works in a very simple environment? Where is your test stub executable to see if the DLL works? Where is the application that is very simple that loads your DLL and tests it? Where is your version of a "vsimk.exe" application that loads the DLL? It isn't that difficult to write one that just loads your DLL and sees what happens.

Right now, you're trying to figure out all of these extraneous processes, executables, who calls what, etc. That is not the way a programmer develops a DLL. You write a very simple application, whether it is a Win32 that calls LoadLibrary()/GetProcAddress() and calls a couple of the exported functions, or an app generated by MFC wizard and use your DLL, etc. Then you debug that application to see how your DLL works with it. All of this extra CAD stuff is totally not necessary, and only adds to the confusion.

If it does not work in a simple application, then get it to work in a simple application. Once you have it working, then you apply it to the larger, more complex application.

Re: How to call Dialog window (formed as resource) from a .DLL

Hello,

After a lot of different attempts I'm hampered an obstacle, that apparently without issue.
The application that calls my .DLL is stopped on the following command (with some error message informing that it's just stop working, without any detail):

Re: How to call Dialog window (formed as resource) from a .DLL

Originally Posted by Pavel_47

When I uncomment DebugBreak() and during pause of 20sec attach to process I can pass through the suspected code.

Those lines did nothing except move the problem somewhere else. Adding in a Sleep() is a sure sign that either you've corrupted memory and the Sleep() just moves the bug to another place, or you have a multithreaded program and your code causes a race condition.

All you're doing when you add and remove lines is to change the executable so that the bug is in another place. I bet if you added a few "int i = 0; ++i", the code would also magically "work".

But the problem is - in debugging mode evrything is OK !

You have either

1) Corrupted memory or
2) Caused a race condition to occur or
3) Using uninitialized variables or
4) A combination of 1), 2) or 3).

Does anybody can propose some work around ?

You have a function, it doesn't work. The only "workaround" is for you to debug and fix the function. Putting in Sleep() is no fix, as right now, it is no different than adding some local variables and incrementing them.