|
|
how can i print input data in dialog based projects??
|
|
|
|
|
|
Hi
I got Bitmap. How can I save it to a file using GDI+?
Bitmap* pBitmap;
.....
Save pBitmap to a file ????
Thanks,
modified on Thursday, July 30, 2009 3:40 PM
|
|
|
|
|
The Bitmap class inherits from the Image class and the Image class has a Save method.
So this creates a bmp file.
CLSID clsid;
GetEncoderClsid(L"image/bmp", &clsid);
pBitmap->Save(L"file.bmp", &clsid, NULL);
This creates a jpeg file.
CLSID clsid;
GetEncoderClsid(L"image/jpeg", &clsid);
pBitmap->Save(L"file.jpeg", &clsid, NULL);
A few more image types are supported.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
If I do this I get invalid parameter from the save. Do you have any ideas why I would get this?
|
|
|
|
|
Have anybody need to type a custom text in StatusBar at first start SDI application ? I want to display something at pane 0 of statusbar at SDI application and no matter how much try that I didn't make it ... I try this in many ways but unsuccesfull : My problem is : in CMainFrame::SetMessageText("My custom message") do not work at first launch : framework display "Ready" ...
|
|
|
|
|
If you edit the .rc file (text editor will work, look for AFX_IDS_IDLEMESSAGE and change it to whatever you like.
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
I try that too but my messages depends of some start conditions and will not always be the same .For sample , if my programs can not connect to a database at first launch , I want type that in statusbar ... Anyway , I apreciate your answer ! Thanks a lot !!!
|
|
|
|
|
Is there a better (simpler) way than using "GetClassName" to check if a window class is one of the general window classes like "EDIT", "BUTTON", etc... ?
|
|
|
|
|
How much simpler do you need it to be?
GetClassName tells you in a single function call.
|
|
|
|
|
I was hoping for a method where I didn't need to create a buffer, call a function, and then do a string comparison.
|
|
|
|
|
Well, how do you envision it happening? Is the program supposed to use telepathy?
|
|
|
|
|
I was hoping there was "reserved" range of integral values for the general window classes, and some symbols defined so I could do something like...
if (::GetWndClassThroughTelepathy(pWnd->m_hWnd)==EDIT_WINDOW_CLASS) {
// We know this is an edit window class
}
O'Well, I guess it'll all make sense to me someday.
Thanks anyway.
|
|
|
|
|
With C/C++ this is as simple as it can get.
Unless you want to have the overhead of a class like CString .
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Hi,
When Creating Objects
For Controls e.g. CEdit, CStatic, etc ....
thr 3rd parm in the Create method is a CRect or
Rect specfying the Size of the Control is there
Anyway to use the Values specfied in the
resource file maybe by using NULL as the Value
it would then look at the resource file for the
Size of the Window Object
thankx
|
|
|
|
|
I assume that you are talking about creating controls in a CDialog derived class. If this is the case and the controls are defined in the dialogs resource then you can simply subclass the controls using their respective objects instead of calling their Create() method. Typically the controls are subclassed through the DoDataExchange() method in the CDialog derived class. If you need to create the controls dynamically use the SubclassWindow() method instead.
class CMyDialog : public CDialog
{
protected:
virtual void DoDataExchange(CDataExchange* pDX);
CButton m_MyButton;
};
void CMyDialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_MYBUTTON, m_MyButton);
}
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
I am a bit confused
The Sublassing concept I thought refers to messages
that were sent to a Control/window
By specfying a Window/CWnd object as the 3rd
parm of the DDX_CONTROL macro accomplish this ??
Is the message stored somewhere in the
CWnd/Cbutton object???
Using DDX prefix for this is still more
confusing as The DDX MACROS seem to refer to the
data in the Control
I unnderstand the button cotrol cann't have
data .....
|
|
|
|
|
ForNow wrote: The Sublassing concept I thought refers to messages that were sent to a Control/window by specfying a Window/CWnd object as the 3rd parm of the DDX_CONTROL macro
Yes but it's much more than that. MFC contains it's own message pump and special handling when creating a window. In order for MFC to intercept messages sent to a window it's own internal window procedure must be called. Anytime you call the Create() method of a CWnd or derived object the window is first created and then automatically subclassed. This eliminates two things; the need for you register a window class (e.g. WNDCLASS) and having to supply a [custom] window procedure.
Dialogs however are a bit different. When you create a dialog it automatically creates all of it's child controls when it receives a WM_INITDIALOG message. This completely bypasses the internal window creation handler preventing MFC from processing messages for that window. Even if you make a call to CWnd::Attach() MFC will not receive the messages for those controls (see below). This also applies to windows created by directly calling Windows API functions such as CreateWindowEx() and CreateDialog().
To solve this problem explicit subclassing must be used. This does three things...first it associates the object with the specified window handle by calling Attach(), second it calls the PreSubclassWindow() method of the object and finally it subclasses the window by replacing the original window procedure with the one internal to MFC. It also does some error checking to prevent a window from being subclassed more than once (the debug build will assert if you attempt this). From that point on the object will receive all window message before the original window procedure is called.
This is important if you wish to provide custom functionality in a derived control class. For instance if you wanted to display a context menu when the user right clicks on a list box item you would need to create a class derived from CListBox and add a message handler for WM_RBUTTONDOWN. If the window control is not subclassed the message handler would never be called.
... to be continue ...
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
This leads us to another question. Is subclassing absolutely required? The answer is no. If you are not implementing any custom functionality for a window or control calling Attach() can work just as well. This allows you to associate the window handle with a specific object and access that window via the objects methods rather than calling SendMessage(). The object will not receive any of the messages intended for the window but you will still be able to access it in a much more friendly manner. The difference however is that you must call Detach() when the controls parent window is destroyed.
There are a few other details that I haven't touched on here but I'll let you digest this first and if necessary we can move on to them. They mainly deal DDX_Control() and what it does above simply attaching or subclassing a window.
Hope this helps.
Bonus time:
ForNow wrote: I unnderstand the button cotrol can't have data
Actually that's not true. All windows can have additional data associated with them by using the GetProp() and SetProp() API calls.
In MFC you can create a class derived from say CButton that contains data and then subclass the button control with an object of your new class. Since that window is now associated with your custom object that data is also associated with it.
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
If I undertand correctly part of what
DDX_CONTROL does is subclass So after calling
DDX_CONTROL are messages for it still
processed thru the Dialogs Message map
or .......
|
|
|
|
|
ForNow wrote: f I undertand correctly part of what DDX_CONTROL does is subclass
Yup yup. exactly.
ForNow wrote: are messages for it still processed thru the Dialogs Message map or ....
Messages intended specifically for the control (any child window really) are dispatched through the controls message map and not through the CDialog's message map. The dialog object DOES however receive notification messages generated by the control. This behavior is defined by Windows itself (child <-> parent relationship) and isn't specific to MFC.
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
THANK YOU !!!
If I took a Class in MFC What would the
Previous Dialog Cost me
Wanta a Free Cheese Burger.....
Thnakx Again
|
|
|
|
|
ForNow wrote: If I took a Class in MFC What would the Previous Dialog Cost me
Much more than a cheeseburger I'm sure lol. Besides CodeProject can be a pretty good classroom so long as you don't make fun of the kid in the corner picking his nose
ForNow wrote: Wanta a Free Cheese Burger
BEEFCAKE!
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
One more thing
Since DoDataExchnge is called for both
Intializing and receving shouldn't I add the
Following code
If CButton.m_hWnd = NULL //
// CButton has not been
// attached
DDX_CONTROL(PDX,IDC_,CBUTTON)
|
|
|
|