If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
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

Originally Posted by VictorN

Pavel, the dialog constructor did accomplish his job.
Perhaps DoModal() had some problems... What did it return?

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ... So, the 1st solution, proposed by Igor (using Create function) probably is the only one. The "restart run" issue must be resolved for correct functionnality.

Concerning return value, I can't get it, because the control isn't returned from it because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

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

Sorry Viktor,

I sent answer before completing it properly. Here is missed message from previous answer:
Concerning return value, I can't get it, because the control isn't returned from DoModal because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

So, I think, the GetLastError function can't be useful here. Or I missed something ?

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

Originally Posted by Pavel_47

Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

No, it isn't the only solution.

The bottom line is this -- you are using Visual Studio. By using Visual Studio, you can attach to any running process and see why it's hanging by using the "Break All" menu option. There is no need for you to use Task Manager to kill the process. Doing things like killing a process because you don't know what else to do shouldn't be an option if you have Visual Studio and you're debugging an application.

Second, are you single-stepping through the program using the debugger? Why can't you debug into DoModal() to see what is going on? If something doesn't return, just go to the Debug main menu and choose "Break All".

Here is CAD tool output window (with vpi_printf function messages):

Use the debugger -- forget about the console output.

Looking at console output from a CAD tool isn't going to get you very far -- you need to know how to debug a DLL and step into the code using the debugger (as Igor already mentioned). Are you debugging your DLL? If not, please spend the time to set this up correctly -- the time spent to learn how to debug a DLL is far much better than waiting for a response from CodeGuru.

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

Originally Posted by Pavel_47

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ... So, the 1st solution, proposed by Igor (using Create function) probably is the only one. The "restart run" issue must be resolved for correct functionnality.

The word "probably" must be eliminated from engineer's vocabulary. To accomplish your job you have to understand your solution. You have to find out why "restart run" works, but first run does not. You have to try different type clients for your DLL. Finally, it's just a DLL that can be loaded to any client, not CAD only. Try to make it working in the simplest environment, and only then move to real situation. Man, there are lots of things that you can do except asking on forums.

Concerning return value, I can't get it, because the control isn't returned from it because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

The highlighted part makes me sure you don't understand very basic things about DoModal. Seems you cannot go forward without getting the most basic knowledge about how MFC works.

You know, I met this kind of situation several times before. People say they have no time to learn the backgrounds, just because the technology they are to use is not their primal whatever, and they have a lot of things to do in their main task/job, and one thing they just want is to do a little (or not so little) thing in an exotic environment along with weird requirements that anybody else on this forum couldn't ever met in their lives.

The combination of exotic environment, weird requirements, knowing nothing about technology in use and not willing to learn the technology they consider be something secondary and hardly necessary in future - this all has no chance to be anything else but a real danger for the whole project. People just don't understand what they do, why what they do behaves like it does, and how to diagnose and where to look at. Dead end. You're not prepared for this task. Try to go with some other technology you're really good at. Or put aside your assignment and get to learning the basics.

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

Dear Paul,

I've followed your advise and tried to debug with WS. Here below is situation after "Break All". What useful information can I extract from this ? As I've already mentionned, this GUI interface is important, but not principal part of the project. I have merely no time to become guru in MFC development, study in depth dbug techniques, etc. I would like to terminate this phase as soon as possible - other part, essential one is waiting for me. Thank you for your comprehension.

So I dare to reformulate the problem hoping that there is more simple solution.
Here is the project that is work properly - at least as I want.
Application Class declaration

The problem with this realization - it doesn't use resources, so all controls and theirs handler on windows must be created manually. As interface can be quite comlicated it could take considerable time. So, the question:What should I change in this working application in order to add resource building facility ?
Sure there will be additional class. But what about application class - what changes should I do there ??

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

Originally Posted by Pavel_47

I have merely no time to become guru in MFC development, study in depth dbug techniques, etc.

Then you need to hire a consultant, since there is nothing "in-depth" in learning how to debug a DLL. Have you placed a breakpoint and have the breakpoint hit by the debugger? If not, then you need to go back and learn how to do this simple thing. If you can't do this simple thing, how are you going to advance from there?

You are using an environment that requires knowledge of debugging, developing, and maintaining. This isn't HTML, Perl, or some other script or script-like environment where everything is easy or with a couple of hours practice, becomes easy. You cannot get away with attempting to write a Windows/MFC C++ application with no knowledge.

As to your screenshot, how is that going to help us? First, it's too small to read. Second, unless you set a breakpoint and step through the program, showing console windows or screen shots isn't helping you or us.

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

Originally Posted by Pavel_47

The problem with this realization - it doesn't use resources, so all controls and theirs handler on windows must be created manually. As interface can be quite comlicated it could take considerable time. So, the question:What should I change in this working application in order to add resource building facility ?

That question alone demonstrates that you have little idea of what you're dealing with.

Creating controls dynamically and have them useful is non-trivial, even for persons experienced in MFC programming. So even if experienced persons need to do research, test, debug, etc. to accomplish this, how do you think you'll be able to accomplish this?

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

I can't use breakpoint inside my .DLL: when I attach to process, the breakpoint becomes inactive (empty circle with triangle and tooltip "The breakpoint will not currently be hit. No symbols have been loaded for this document"). I've serched for hours on the web for a solution, but without success. Probably reason (appologize in advance for employment the word "probably") - the tool executables have no accompagniing .PDB database files. With "Break all" I succeeded (not without difficulties) to have CallStack.
Here it is
Regards

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

Originally Posted by Pavel_47

I can't use breakpoint inside my .DLL: when I attach to process, the breakpoint becomes inactive (empty circle with triangle and tooltip "The breakpoint will not currently be hit. No symbols have been loaded for this document").

Did you build the DLL with debugging information?

I've serched for hours on the web for a solution, but without success. Probably reason (appologize in advance for employment the word "probably") - the tool executables have no accompagniing .PDB database files.

The PDB files exist if you build the DLL with debugging information. If you did build the DLL yourself with debugging information, then the reason most likely that you cannot debug it is that the DLL that's running is not the one you built, but some other version.

Look, it's very easy.

1) Rebuild the DLL, making sure that debugging is turned on (both compiler and linker settings).

2) Start the CAD program. Make sure that your CAD program is using that same DLL you built. If the CAD program is using some other DLL that happens to have the same name, then of course you won't be able to debug the one you just built. Using Process Explorer from sysinternals.com shows you what DLL's are loaded when the program is running.

3) Set a breakpoint in the DLL function in Visual Studio.

4) Attach to the CAD program. Then do something in the CAD program that invokes the DLL function you set a breakpoint in.

5) Done.

It can't be any easier than that.

You don't need to attach to the CAD process. The other way to debug is to start the CAD program from the DLL project itself. If you know the command to start the CAD program, then enter the name there, set a breakpoint, and start debugging.

If you want proof, don't make any changes, go to your DLL project and try to debug by hitting F5 or F10. What do you see? Don't you see Visual Studio asking for the name of the application? So what is the name of the application you're trying to debug? You don't need google or hours of searching to see this -- just by accident hitting F5 or F10 would have given you a clue on how to debug a DLL project.

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

Here it is:

1) Rebuild the DLL, making sure that debugging is turned on (both compiler and linker settings).

For compiler it should be Ok:
For linker also:

2) Start the CAD program. Make sure that your CAD program is using that same DLL you built. If the CAD program is using some other DLL that happens to have the same name, then of course you won't be able to debug the one you just built. Using Process Explorer from sysinternals.com shows you what DLL's are loaded when the program is running.

This is checked in point 4 (you will see). When the CAD starts some process, called "elaboration", it loads specified .DLL, that is specified in project conf. file. The name of the .DLL is displayed in the CAD console window

3) Set a breakpoint in the DLL function in Visual Studio.

4) Attach to the CAD program. Then do something in the CAD program that invokes the DLL function you set a breakpoint in.

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.

You have to place some code to InitInstance that will collect information about process (timestamp, .exe path and PID) and dump that to some file where you can inspect that (or console if you prefer that way). Please note that such offline debugging is the oldest debugging technique, but it still remains to be the most reliable one.

As well, you may try with DebugBreak and see if JIT debugger window shows up.

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

Originally Posted by Pavel_47

Here it is:

What is the full path name of the DLL you are trying to debug? Do you see it in the list of modules that are loaded? So far I have no idea the name of the DLL that you're trying to debug, or the full path of that name. Why are you showing us names of DLL's that are not relevant?

Please show only the full path name of the DLL that you claimed you built, and that it was or was not loaded with symbols. It doesn't matter whether "vsim.exe" was built with debugging information or not. What matters is the DLL you built and whether that is being loaded with debugging information.

Moreover, this issue has nothing to do with debugging -- do you really know yourself what DLL's are being loaded by which process? Forget about Visual C++, do you know how your application really operates? Honestly, I don't think you know for sure which DLL's are being loaded and where they are being loaded from.

You should be using Process Explorer from sysinternals.com or some other application that shows you exactly what DLL's are being loaded by a process. These are basic system tools, regardless of whether you know MFC/C++ or not.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.