|
No, I mean I have my windows designed and laid out and I just want to code the button so it closes down the window it was clicked in and opens up another window specific to the button that was clicked..... Does that make sense ?
** I am really new to Visual C++..... I am supposed to make a basic game in it. **
(Still not got the thing to work though)
Cheers.
P.S. If you're not living life on the edge you're taking up too much room.
From Crazy Skydiver.
|
|
|
|
|
I haven't done this in MFC yet but I think it would be something like this.
In the button handler for the first dialog, DlgA....
void DlgA::OnButton1Click()
{
CMyDialog MyDialog();
MyDialog.Create(..parameters if needed);
MyDialog.ShowWindow(true);
}
|
|
|
|
|
I bought this book "Windows 98 Programming" by Schildt [osborne/mc graw hill] on sale for $5, and this guy says you must learn Win32 API before learning MFC, is this true ?
I thought MFC was an abstraction away from WinAPI calls.
Soliant | email
"The whole of science is nothing more than a refinement of everyday thinking." -Albert E.
|
|
|
|
|
you will still need to learn some of the Win32 API. MFC doesn't hide all of the details. plus it certainly helps to understand what the various MFC classes are actually doing (especially when it comes to GDI objects).
-c
WWJD? JWRTFM.
found on /.
|
|
|
|
|
Well, you needn't, but it makes life alot easier if you have at least basic knoledge in Win32 API. MFC is not a very deep abstraction of the API, e.g. many funcions like adding an entry into a combobox AddString() do nothing else but directly calling Win32 API (SendMessage e.g.)
I have my own philosophy: I use MFC to create dialogs or MDI/SDI apps, but still use very much API calls directly.
Furthermore not every single API call is encapsulated by an MFC class, that's why you often must use API to get things to work.
reagards
Greg
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Thanks guys, you think Jeff Prosise "Programming MFC" is a good way to go?
Soliant | email
"The whole of science is nothing more than a refinement of everyday thinking." -Albert E.
|
|
|
|
|
Yes, yes, YES! One of the best books - possibly THE best one. You will not be disappointed.
Cheap sex and sad films. Help me get where I belong.
|
|
|
|
|
It'll be a MASSIVE advantage as MFC is only a very thin wrapper for the Win32 API.
Stop sending letters. Letters always get burned.
|
|
|
|
|
Soliant wrote:
you must learn Win32 API before learning MFC, is this true ?
"Yes", if you want to fully understand MFC and program in it.
"No", if you're coming from an X/Motif/Mac/Qt/Tcl background and just want to create a one-off Windows app.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Not at all - I think it's better to learn MFC then learn what the Win32 API is doing for you, because you can learn incrementally instead of all at once.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
hi
how way to follow learn to mfc."programing windows jeff prosise" this book is very good.but other good books are which? 
|
|
|
|
|
zeki wrote:
but other good books are which?
Here's one for ya! 
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
sorry...
may english is not good..
|
|
|
|
|
Hey, no worries - don't take it as a slam, it really *is* a good book! 
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Soliant wrote:
I thought MFC was an abstraction away from WinAPI calls.
Yes, but (fortunately) the abstraction is just a pretty thin wrapper on API. I'd say API knowledge is big advantage.
Tomasz Sowinski -- http://www.shooltz.com
What is "scratch" and why can everything be made from it?
|
|
|
|
|
You don't need to know it. For my first year back in 1993, I pretty much managed without knowing too much API. Over the years though, you soon realise it's nice to know the API too - especially when hitting the limits of MFC's scope.
Michael
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
 I am trying to use SAX in my Dialog Based Application .
I have a SAXHandler class that derives from the DocumentHandler that SAX provides.
My Dialog Class has a SAXHandler object and a SaxParser Object .
I am having problems when I link the project.
Errors I get are of the type
SAXdev.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall SAXParser::~SAXParser(void)" (__imp_??1SAXParser@@UAE@XZ)
SAXdevDlg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall SAXParser::~SAXParser(void)" (__imp_??1SAXParser@@UAE@XZ)
SAXdevDlg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall SAXParser::SAXParser(class XMLValidator * const)" (__imp_??0SAXParser@@QAE@QAVXMLValidator@@@Z)
What is the correct method to add the files ?
Please help
|
|
|
|
|
did you implement a constructor and a destructor for your SAXParser object ?
-c
WWJD? JWRTFM.
found on /.
|
|
|
|
|
I did not . The SAXParser class is in a .hpp class and is as follows :
class PARSERS_EXPORT SAXParser :
public Parser
, public XMLDocumentHandler
, public XMLErrorReporter
, public XMLEntityHandler
, public DocTypeHandler
{
public :
// -----------------------------------------------------------------------
// Class types
// -----------------------------------------------------------------------
enum ValSchemes
{
Val_Never
, Val_Always
, Val_Auto
};
// -----------------------------------------------------------------------
// Constructors and Destructor
// -----------------------------------------------------------------------
/** @name Constructors and Destructor */
//@{
/** Constructor with an instance of validator class to use for
* validation.
* @param valToAdopt Pointer to the validator instance to use. The
* parser is responsible for freeing the memory.
*/
SAXParser(XMLValidator* const valToAdopt = 0);
/**
* Destructor
*/
~SAXParser();
//@}
It was said that in SAX one needs to only implement the Handler class that derives from Documenthandler
then we need to invoke
parser.SetDocumentHandler(& handlerobject)
parser.Parse();
The sample code I referred from a Text book did not have any initialization for the parser object .
Please help
|
|
|
|
|
you can't declare a constructor (or destructor) and not implement it.
at the very least make them do nothing:
~SAXParser()
{
}
SAXParser::SAXParser(XMLValidator* const valToAdopt = 0)
{
}
WWJD? JWRTFM.
found on /.
|
|
|
|
|
I manually put in .bmps in my access database (its a valid thing to do). The images are of type Ole Object. I am trying to retrieve them in the following:
memcpy(pImage, (char *) (_bstr_t) m_pRecordset->Fields->GetItem ("pImage")->Value.bVal,
ImgSize);
where pImage is allocated big enough . So evidently I am not casting the value right. I do need a char* to show in my ImageBoxes(thats what they take), but my code crashes exactly at the line above. I havent figured out how to inspect and see if the image is valid etc, any ideas as to how I could do that?
Thanks for any help you can give me.
ns
|
|
|
|
|
cast pImage to a BITMAPFILEHEADER * and look at the members. they should reflect various aspects of your image.
-c
WWJD? JWRTFM.
found on /.
|
|
|
|
|
It may be coiming in as a pointer to bval, i.e.,
m_pRecordset->Fields->GetItem ("pImage")->Value.pbVal
Not sure. But may be
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
tho.