|
I think you might be better looking into WTL first before moving to straight Win32 API. WTL is a much smaller and cleaner framework than MFC.
The Charles Petzold book will give you a good grounding in Win32 programming. Not sure of the current title as my copy is Programming Windows 3.1
Michael
Logic, my dear Zoe, merely enables one to be wrong with authority. - The Doctor
|
|
|
|
|
Would you happen to know any good books which cover the WTL basics then?
|
|
|
|
|
The Petzold book is an excellent tutorial. Btw, you can (and should!) continue to use classes.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks, I'll see if I can find it.
Oh.. and I didn't want to stop using classes, only the CString, CDialog, and those are the ones I wasn't particually fond of.
|
|
|
|
|
STL will handle the string classes using std::string. WTL will give you a nice thin framework for CDialog.
You could write your own framework, do a search for Windows++ for an example.
Michael
Logic, my dear Zoe, merely enables one to be wrong with authority. - The Doctor
|
|
|
|
|
I've read "Win32 Programming" by Brent Rector and Joseph M. Newcomer. It's an excellent read and a great reference book. My copy started to fall apart because I used it so much when learning pure Win32 programming.
Also, Joseph is a registered CPian and well-respected programmer. Take a look at some of his articles to see the quality of his work. This is also reflected in the book.
Jeremy L. Falcon<nobr>
Homepage : Sonork = 100.16311
"Victims falling under chains ~ You hear them crying dying pains
The fist of terrors breaking through ~ Now there's nothing you can do"
Song: Phantom Lord - Album: Kill 'em All - Artist: Metallica
|
|
|
|
|
How can I obtain the handle to a disabled control(button) in one application and enable it from another application.
Thanks
|
|
|
|
|
use FindWindow function to get the handle of your control,then you can do what you want on that control.
|
|
|
|
|
Hi,
My application handles the CTRL+Z/Y to make my "undo/redo" stuff, but I´m having problems, when the focus is ( for example), in an edit control, then I don´t get that message ( the edit control handles it), is there anyway to aviod that ( without use the bag of problems called PreTranslateMessage...).
Thanks in advance, Greetings
Braulio
|
|
|
|
|
I've followed the tutorial about creating office addin's. The one I've created is an excel addin. It doesn't do anything, it's just a minimal addin.
But it doesn't show up in the excel addin-list, even though it's registered in windows registry.
The loadbehaviour should be set to 3 for automatic loading.
After compiling the project, using regedit shows 3 for loadbehaviour. So far so good.
But after running excel, eyeballing the addin is not there, the loadbehaviour in regedit changed to 2 ??????
What's going on here?
[VISUAL STUDIO 6.0] [MFC] [WIN98/2]
Bluute tette!
|
|
|
|
|
I am a little embarrased having to ask about this, but I have a need to change the font size/style of a static text field and I can't remember how to do it. My old code library is at my last job and I don't have access to it anymore. Is there anyone out there with a lead on where I might go to quickly solve this problem? Thanks for any help you can give!
Dan Broomall
GIS Programmer/Analyst
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
- Albert Einstein
|
|
|
|
|
|
You can change the font for the whole dialog by bringing up the properties for the window in the dialog editor. This font will be used by everything else on the dialog too, though
--
Help me! I'm turning into a grapefruit!
|
|
|
|
|
I got from the MSDN this snippet about enabling/disabling menus. I put it in a button click event (for starters). I got a debug /assert. Where should it go?
Please let me know.
Thanks,
ns
In the real project its supposed to happen after a successful login from a modal dlg box spawned off an MDI CFormView form:
In a doc menu click event:
{
CMyDialog cMyDlg;
int ret = cMyDlg.DoModal();
If (ret==5)
{
CMenu* mmenu = GetMenu();
CMenu* submenu = mmenu->GetSubMenu(0);
submenu->EnableMenuItem(ID_FILE_NEW, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
}
}
|
|
|
|
|
I suspect you're running into a null pointer problem. If this code is in the CFormView object, GetMenu() will return NULL because the menu doesn't actually belong to the view, or even to the view's parent frame. The application's menu belongs to the main frame, so you need to do this instead:
CMenu* mmenu = AfxGetMainWnd()->GetMenu();
But if I were you, I wouldn't do it that way anyway. I'd add a member variable to your document class, which you would set when you did the login. Then, add an update handler to your document class for ID_FILE_NEW (the easiest way to do that is via ClassWizard), and enable or disable the menu item based on that member variable:
CMyDocument::OnUpdateFileNew(CCmdUI* pCmdUI)
{
pCmdUI->Enable(m_bLoginOk);
}
That way, if you had a toolbar button for file new, that would also be enabled or disabled correctly.
"We are the knights who say Ni" (The Knights Who Say Ni)
|
|
|
|
|
Thanks. Thats what I ended up doing . Didnt know the tooolbar button would follow suit though...
many thanks.;)
|
|
|
|
|
Hello,
I have a little experience in MFC, but almost none in Win32 programming and callback functions.
I am working on a dialog based MFC project and need to use some third party stuff that require a callback function. I have no idea how to move on. Where should I declare the callback function? It should be stand alone and not belongs to any class, right? Is it possible to handle the callback like a message handler in the MFC way? Any help or quick pointer to useful resources would b appreciate.
By the way, any good online resource about the basic of callback function? All the stuff I have found seem too advance to me
|
|
|
|
|
You need to know what prototype it should be, then
you either declare it global or as a static class member.
returntype CallbackFn(params)
{
// Handle stuff in here.
}
Then you use 'CallbackFn' as param where te 3'rd party lib wants
a callback function.
/Magnus
|
|
|
|
|
Its (somewhere) in the MSDN, an example of a function in a class as a callback function for Multi-threading. First, create a separate function that is "static" (for thread use, UINT <funcname> (LPVOID)):
class MyClass
{
..
// Callback Function
static UINT MyCallBackFunc (LPVOID lpData);
// Actual Function
void MyFunction ();
..
}
UINT MyClass::MyCallBackFunc (LPVOID lpData)
{
MyClass *pMC = (MyClass *) lpData;
if (pMC)
pMC->MyFunction ();
}
// Use of the callback function - AfxBeginThread is a member of CWinThread
..
AfxBeginThread (0, MyCallBackFunc, this);
..
when assigning the callback function, use the MyCallBackFunc passing the instance of the class as the parameter.
this is just an example to give you an idea; better look for the actual code (I'm not 100% sure with this one. gud luck.
|
|
|
|
|
I edited the string in the string resource of my MDI project. In the fourth (tried the 5th place too) place I put \nCoin Project (*.coi), which according to my example should have opened the file/open dialog with a filter of *.coi. However it always says All File (*.*).
ANy suggestions? Is there a direct way by code we can do this?
Thanks in advance,
ns
|
|
|
|
|
I believe that, in C++, if a function may throw an exception, you should declare it like this:
<br />
int myfunc() throw (CMyException);<br />
The problem is that VC (even .NET) issues a warning that it disregards my declaration as the ANSI standard is not very specific when using functions that throw exceptions. In fact, I think the function may very well throw an exception of another type, not the one declared.
The question is:
Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use the throw (CMyException) both in the header and the implementation file?
Best regards,
Alexandru Savescu
|
|
|
|
|
The function my thow any other exception, but if it do so your aplication will be terminated because the 'unexpected' handler will be called witch by default call 'terminate'. To set your own handler you can call 'set_unexpected()'.
For a more deep perspectiv on exception you can see "Deep C++" in MSDN
Bye,
Orbital^
...the night is long ... but not long enought to do some real coding ...
|
|
|
|
|
Are you saying that if I do:
void f () throw (MyException)
{
throw OtherException();
}
void g()
{
try
{
f();
}
catch (MyException)
{
}
catch (OtherExcepion)
{
}
}
my application will be terminated. I doubt it!
Best regards,
Alexandru Savescu
|
|
|
|
|
In ANSI C++ the program will be terminated but as Visual C++ documentation say : "A function is declared using exception specification, which Visual C++ accepts but does not implement". If you want to write compatible code you should respect ANSI specification.
MS say : "Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications."
Bye,
Orbital^
...the night is long ... but not long enought to do some real coding ...
|
|
|
|
|
Alexpro wrote:
The question is:
Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use the throw (CMyException) both in the header and the implementation file?
Exception specifications in C++ are broken. If you specify a function as having an exception specification (and if the compiler conforms to the standard) then any exception that the function throws that isn't in the specification causes the unexpected exception handler to be called which defaults to terminating the program.
This is considerably different to how they work in Java. Java has static checking of exception specifications which means that you can't write a function that calls another function yet doesn't either handle the exceptions specificed in the other functions exception specification or declare that exception in its own exception specification. It's a complex problem to make a C++ compiler do this static checking as it would most probably need sight of all source used for a start as there's probably not enough information in the resulting object files. There's then the issue of whether it's a good idea to have it do that checking...
In Java it's often a pain to have to modify lots of code when a library changes its exception spec. It wouldnt be so bad if the callers actually did stuff with the new exception, but often they don't, they just pass it on up the chain. Of course if each library caught every exception and translated the appropriate ones into their own more descriptive exceptions then that wouldnt be so bad, but you can find yourself upgrading a library and suddenly having to deal with 'blah.blah.sublibrary.we.now.use.exception' which, as I said, is a pain. If everyone did the right thing it would possibly be a good thing and add value, but people, being people, dont, and it isn't.
So, my view is that in Java it's a pain and isn't used properly and in C++ it's a liability and should be avoided at all costs unless you want your programs to just terminate randomly. To write robust code in C++ using exception specs you would need to wrap all access to any code that you didnt have sight of the source of in a try/catch block which translated all exceptions into something you knew. If one developer fails to do that in one library anywhere in your source tree then your program may just decide to exit. To be really sure you'd have to wrap ALL code in such a block. This isn't really such a bad thing, it may look nice to have that kind of rule on your coding standard, but IMHO it sucks Part of the nice thing about exceptions is that you dont need to fill each function in the call stack with error handling gunk which obscures the purpose of the real code. Most of the time you can let exceptions flow up through your code unobstructed. If you expect them, and can deal with them here, fine, you can do so. If you dont then as long as you deal with them at key places (COM interface boundaries, thread/process boundaries, etc) you can write robust code that handles even the most unexpected of exception in a graceful and recoverable (well you can try) manner.
In VC++ at present it's even worse than that as it doesn't enforce them, so they may as well just be a comment with interesting syntax and you really don't want to get me started on comments
Len Holgate
www.jetbyte.com
The right code, right now.
|
|
|
|