you helped me to realize that the "orignal" lParam PDEV_BROADCAST_HDR structure contains the PDEV_BROADCAST_DEVICEINTERFACE structure.
So the cast did not point to anything unknown.
I missed that.
Yeah, you often get neted structs in Windows, with a base type at the start and other structs after that in memory, so there is lots of casting rom one type to another whcih is just to access the 'extended' data.
I have 11thousand PDF file and I need to take a log of number page in each PDF document and I decided to make tool to read the number pages in each PDF document. Anyone can help me. I have VC6 and visual studio 2008.
You need to get hold of one of the PDF libraries available on the internet, or use the documentation available on the Adobe website to write your own. You can then read your PDF files and get information about the content.
One of these days I'm going to think of a really clever signature.
As you may already know, new string literals in C++ 11 can be expressed in a very flexible way.
R"<delim>...<delim>"; - in this code the <delim> can be pretty much everything and also no escape characters are needed. Any kind of parentheses can be used to delimit the end of string, Raw string literals are especially useful when defining regular expressions:
R"(I love those who yearn for the impossible. (Von Goethe, "Faust"))";
Blocks of text can be simply defined using equal occurrences of same characters:
R";***************************( ; TINY BASIC FOR INTEL 8080
; VERSION 2.0
; BY LI-CHEN WANG
; MODIFIED AND TRANSLATED
; TO INTEL MNEMONICS
; BY ROGER RAUSKOLB
; 10 OCTOBER, 1976
; ALL WRONGS RESERVED ) ;***************************";
I understand that the reason the ret variable will not print (it's at the end of the string when destination is passed) but can't figure out how to return destination out of the my_strcpy() function. I can make this work using array notation but not pointer arithmetic. Here's the code in question:
It seems that I have problem drawing ownerdrawfixed combo box, which is actually drawn in ownerdraw listbox control.
I am able to draw all items inside shown dropdown of combo box. But I can not draw anything to combo box "header".
1. What is actual message of drawing combobox "header" ? I got to conclusion that when itemID is -1 (after I call CB_SELECTSTRING) then it is "header" (Note: Seems that right rect is found in DRAWITEMSTRUCT) and I draw text than but nothing appears.
2. Currently I am trying to draw it after CB_SHOWDROPDOWN is set to true. Should it be done before that?
I'm guessing, handle the WM_DRAWITEM message in the parent window, then check the CtlID
member of DRAWITEMSTRUCT to see it's the correct combobox control, if so check the itemState member to see if it is ODS_COMBOBOXEDIT, and if so, draw the edit box (I think the edit box is what you mean when you say "header")control of the combobox.
I have one question regarding resolution. How to make a project created as a MFC dialog based application, resolution independent. I am using a number of images in our dialog based project. But the final display using images and controls is not resolution independent. To say if your PC screen resolution is different from the other, it will not properly display the dialog. Some of the part of dialog display will be cut-off.
How to make the same resolution independent, so that irrespective of the resolution of the device or screen size, display should be same.
Any help will be appreciated.
Also, what is the use of ActiveX controls in MFC.?
I assume that your dialog is created using a resource template.
The simple solution is to limit the size of the dialog to the minimum size of supported screen resolutions.
If your application must also run on small screens, you may add a second dialog template with smaller controls and smaller total size. Upon program start, choose the small template when necessary.
The complex solution would be making your dialog and some or all controls resizable. But this requires proper calculation for sizes and positions of all controls.
There is no need to use ActiveX controls if your application design can be done using the standard Windows and MFC controls. If you have special control requirements, you can build your own controls by using ActiveX or plain C++ code, or use existing controls that fit your requirements. Finally, it's up to you to decide to use ActiveX controls or not.
Thanx for your reply.
It is not that my project will run on smaller screeens only. It may run on larger screens also.
Let me explain, I have windows 7 & my PC screen is of bigger size (vertically as well as horizantally) (bigger than a normal LCD display). if I run my project on my PC, I am not able to see the controls on the bottom of the dialog. if I run my project on any PC with windows XP and screen size is small, it will display it perfectly.
I want to make it like that all the controls should adjust them accordingly irrespective of the resolution or PC screen size.
But then I don't understand why portions are not visible on a big screen. Because with a template based CDialog the size of the dialog and sizes and positions of all controls are defined in the template. As long as nothing is changed by code, the dialog should be shown like in the resource editor. If the screen is larger than the dialog, your app should be opened with centered dialog. If the screen is too small, the right and/or bottom sides are clipped.
Sorry for any confusion.
What I understand is, we are using images for all the controls, whether its a button, static control, slider control etc..... So i thought the image size will never change irrespective of the resolution or the size of the screen. Because image size will remain the same.
its a dialog based app, I also want to understand what makes it that when I open it on screens with different sizes, some controls at the bottom are not visible.
Even with images the sizes of the controls are usually not resolution dependant because this would require repositioning inside the dialog to avoid overlapping.
It seems that you are using non standard controls but custom ones. So you should have a look into the sources and/or the documentation of these custom controls to know what happens. You may also use the debugger to check if missing controls are created or not and get the sizes and positions of these controls (e.g. by calling GetWindowRect() and printing the values to the debug output window using TRACE).
Design all your dialogs for the smallest resolution.
Then when your application runs, check the resolution and see how much extra space you have in the X and Y directions.
Divide this extra space among the controls in your dialog. The extra space shouldn't be divided equally -- Some controls benefit more from extra space than others. For example, a Static or Edit control wouldn't be helped by more Y-direction space, but a List Box would be able to show more items.
Likewise, some space between controls will appear better when extended than other space.
For each dialog, you can list the percentage of extra space you want to add to each control.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"