|
Clark Kent123 wrote: I have a C++ MFC static library dll file.
DLL stands for Dynamic Link Library, it is by definition not static. Also, you state below that it is a COM component, are you sure it is built with MFC classes? You also need to check that the final component was built with DEBUG on so that the debugger can match the object code with the source file. You could test this further by setting a breakpoint in the VB code at the point where it calls one of the C++ functions and see if you can single step into the DLL.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Thanks for the response.
It seems that I may need to clarify a few things. That is my fault. My original message may have skimmed over a few details.
The reason why I wrote MFC static library was because under the C++ properties page I have the following...
Configuration Type: Dynamic Link Library
Use of MFC: Use MFC in a Static Library
Use of ATL: Not using ATL
I have not have had a chance to work with MFC and because of that I am at a loss. What I have worked on in the past (completely different program) is the use C++ to create COM objects and that way make it aware in other programming environments such as VB. But this particular C++ program is not a COM object. Every time I try to load the DLL file in VB using the Add Reference it tells me this is neither a valid COM object or assembly.
I have not been in this situation before so this is left me scratching my head saying how do you debug this? Do you have any suggestions?
This is what I am attempting to do. I have my main VB program and I add the C++ solution to the main project. I place break points in the C++ program and when I step through the main (VB) program it does not halt within the C++ cpp file. Upon mouse over the breakpoint the compiler tells me "The breakpoint will not be currently hit. No symbols have been loaded for this document."
I made sure in the Configuration Manager that all the programs or solutions are defaulted to "Debug" setting.
Any suggestions?
|
|
|
|
|
One thing you could try is to set the C++ DLL as the start up project in your solution, get the VB program running, then attach the debugger to it. I have had success in the past doing that with C# and C++ DLLs.
|
|
|
|
|
I will give this a try and hope this gets me what I need. Thanks for the suggestion!
|
|
|
|
|
Clark Kent123 wrote: Every time I try to load the DLL file in VB using the Add Reference it tells me this is neither a valid COM object or assembly.
So you are not even at the point of being able to debug anything yet, since you cannot get to the library. In order to use a C++ DLL from VB.NET you need to make that library into a COM component, or provide a pure Win32 interface which you can then access via the Platform Invoke feature[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I had a feeling you were going to say that. I was hoping that I was wrong. So because this DLL is not "exposed" it limits my debugging severely. 
This makes things interesting now. Thanks for confirming this for me.
|
|
|
|
|
Clark Kent123 wrote: because this DLL is not "exposed" it limits my debugging severely
Well, more than that, it means you cannot even start to use it. As I said above you can only access it via COM, or through P/Invoke.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Yes, you are correct. In my VB program I am using the P/Invoke technique to call this library of C++ functions. But it's not fun that I can't debug it. 
Oh well. The original author did it this way and it's going to take so much work to make it a COM object. Not sure if I want to go down that path. But thanks for the info.
|
|
|
|
|
"Whenever I place a breakpoint in the cpp file and run the main program (VB) the breakpoint I placed in the cpp will not be hit according to the compiler."
When debugging managed code that calls unmanaged code, there's a setting (in Properties | Debug) called "Enable unmanaged code debugging". If this isn't checked, the debugger won't step into the unmanaged code.
|
|
|
|
|
Hello Friends
I am creating an application in which m sending data to printer for printing using COM and LPT port.Now, I want to do same using USB port.
For COM and LPT port,am setting port first by using fn CreateFile which Gives me handle of COM and LPT port.To createFile fn,first parameter is name of port that is COM1,COM2.. And then sending data to that port and Its working fine.
Now,For USB, I tried GetRawInputDeviceList but its not returning me any HID device.
Or there any other way to detect USB device?
Thanks In Advance.
Yogesh
|
|
|
|
|
You can use the Printer APIs -
EnumPrinter
OpenPrinter
WritePrinter
ClosePrinter
Here is the list of all APIs - Print Spooler API Functions[^]
|
|
|
|
|
Thanks For Reply. But I am not facing any prob in printing.I already created a application which takes care of job added and Queue.
Main problem is now with USB device,how can I get the Handle of that. How can I enumerate the USB device name list ?
Or if ther is any function in printer spooling which enumerate USB devices,let me know,I didnt get from this printer spooling fn.
Yogesh
|
|
|
|
|
USB devices can be enumerated with the Setup API functions (SetupDIGetClassDevs() to specify a class like USB devices, SetupDiEnumDeviceInfo() to enumerate the devices, and SetupDiGetDeviceRegistryProperty() to retrieve properties).
But this may not help you. Even if you identify an USB printer and opens a connection to it, you must know how to communicate with the printer. This information is printer manufacturer and model dependant and usually not publicly available.
|
|
|
|
|
|
You need to register for device change notification events specifying the USB UID. And on start up you need to enumerate the device already there.
It is a two stage registration process, by type then by handle, that way you get the device removal notification event and you can release any handles you have open on the device (else you screw the system up).
Dont have any links but the SDK should provide all the funcs you need if you search for 'device change notification'.
--edit--
Actualy google threw this up straight away: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363432(v=vs.85).aspx
==============================
Nothing to say.
|
|
|
|
|
Dear Friends,
I am working for MFC application. But I dont know about MFC architecture, classes, why CWinApp, CDocument, Cview and where execution starts and execution flow etc... Iam keen to learn all those things. So kindly anyone help me.
Thanks and Regards,
S.Shanmuga Raja
|
|
|
|
|
Hi There ,
MFC architecture is too big to be discussed on a forum .
I would suggest you go through the book of Jeff Prosise, to understand it better .
Sujay Ghosh
Blog : http://sujay-ghosh.blogspot.com
|
|
|
|
|
|
|
For an insider understanding of MFC, you can have a look at the MFC Internals[^] books.
Nihil obstat
|
|
|
|
|
MFC Internals would be too much for him. Right now , he is trying to understand the MFC architecture . 
Blog : http://sujay-ghosh.blogspot.com
|
|
|
|
|
If I remember correctly, that book, while being more "advanced", was a good reading and help understanding the mess that was MFC; it is a little better now.
Nihil obstat
|
|
|
|
|
Hey guys!
Does any of you have an idea how GDI+ -when filling a rectangle or a region with a color that has an alpha component set- decides to use dithering instead of "real" blending? We are using a third-party library to generate PDF files. When using a printer DC as a "reference" to generate the PDF document, GDI+ seems to use "normal" color blending when filling an area with a translucent color, but when using a screen DC to do the same it "magically" decides to use dithering which produces a "less satisfying" result.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
In many cases, the device driver determines how the GDI+ functions operate.
The printer driver for your printer may not support alpha blending.
You might try using a memory DC to build up your graphics, then blitting that to your printer DC.
|
|
|
|
|
It's the other way around actually (read my original post again), when using the printer, i get alpha, when using a screen based DC, i get dithering, this is why i don't understand it, since i KNOW that i can use e.g. AlphaBlend[^] on the screen without any problems, or if i use GetDeviceCaps[^] on the screen DC i see that it supports blending.
I kinda know that the capabilities of the device is -at least usually- determined by the driver "under" it, what i would like to know is what GDI+ does to come to the conclusion that the screen-based device is incapable of blending and thus resorts to "low quality" dithering.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
