|
Thanks.
I will continue using the modal for now. A modeless has more features like interactive with the view class in real-time. Since this is the first design, I will use the modal to keep everything simple.
Kuphryn
|
|
|
|
|
Conventionally speaking, should the dialogbox (progressbar) comes first or the access data processing. In other words, when creating a progressbar inside a dialog box, should I begin data manipulation, which is what the dialog box will ultimately depend on to update the progressbar, *before* creating the dialog box or *after*? Either way, it looks like I will need to seen a message to the MainFrm or view after InitDialog() in the dialog box.
Kuphryn
|
|
|
|
|
I have two questions...
First:
I'm having a hard time tracking down a problem in my app. I'm using BitBlt to render a bitmap from memory onto my dialog and after a while the images start getting painted onto the desktop and everything gets jumbled up. I checked all my GetDC()'s and made sure to I am ReleaseDC()'ing them and it seems ok on that note. If you have any idea why this might be happening please enlighten me!
Second:
Does anyone know of a freeware app that will tell you how much memory in bytes your app is using in realtime? Or is there a way this can be accomplished with the vc6 debugger?
Thanks,
Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
First:
When you release the DCs, are you properly freeing your memory DCs and BITMAP objects as well?
Second:
There are a number of things that you can do with the _CRT set of debug functions to find memory leaks.
Checkout my Guide to Win32 Paint for Intermediates
|
|
|
|
|
kilowatt wrote:
When you release the DCs, are you properly freeing your memory DCs and BITMAP objects as well?
The DC I am releasing is the dialog's dc.. like..
CDC *pDC = MyDialog.GetDC();
pDC->BitBlt(...);
MyDialog.ReleaseDC(pDC);
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
|
Yes, those are used as the source and the dialog's DC are used as the dest.
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
I figured that you were using a memory DC as the Source, I was just wondering how you were managing those resources. Could you post your code where this is being painted and I will see if everything is in order, or if you do not want to post it to the forum, email me and I will get back to you?
Checkout my Guide to Win32 Paint for Intermediates
|
|
|
|
|
Does anyone know why Visual C++
6.0 tells me this?
How do I find mfc42u.lib and how
do I tell Visual C++ 6.0 where it is?
That is if mfc42u.lib is not obsolete or
something ... if it is obsolete what has
replaced it?
As you can see I am a complete newbie.
|
|
|
|
|
You must not have UNICODE libraries installed (thats what the u stands for). If you are running anything other that Windows NT, 2K, or XP you won't need to compile UNICODE because 3, 95, 98, and ME use MBCS not UNICODE. Check which build settings you are using. If you want to change the build just pop open project settings - linker and change _UNICODE to _MBCS
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179:BestSnowman
†
|
|
|
|
|
|
Hi.
I had an interesting conversation with a programming (C++, Java, and soon, C#) professor at my college.
Background
----------
I am current practicing design and implementation using MFC. I am proficient with C++ and is gaining considerable experience with MFC.
Scenario
--------
I asked the professor if she teaches MFC in one of the upper-division programming courses I am planning to take next semester or the following semester. It is basically a couse on OOP C++, which I understand well now. I asked her if he teaches MFC. She says yes. However, I asked her aid who has taken that same course with her just an hour earlier, but he said there was no courses on MFC. The course that the professor teaches is more on OOP C++ concept.
Anyways, she went on to say that C# really interests her. So the conversation went on, but there was one thing that caught my attention. She said she *heard* that Microsoft is planning to *not support* MFC in the near future. What?
What is the future of MFC? Is C# affecting it at all?
I think C++ w/ MFC (or Win32 API) is the most powerful Windows programming tool.
Thanks,
Kuphryn
|
|
|
|
|
I can't see MFC disappearing anytime soon.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179:BestSnowman
†
|
|
|
|
|
MFC remains the best all around tool available for creating large scale desktop windows applications. Like VB, C# is great for forms based UI design, especially on the web side, but it would not be the best tool to use if your goal is a full scale windows application. Currently, I think WTL is actually about the only threat to MFC.
MFC does *not* constitute good OO design and I, for one, would not be sad to see it replaced. I am actually surprised that they teach it in college. I hope MS does come out with a superior app development tool in the near future, C# or not.
"There's a slew of slip 'twixt cup and lip"
|
|
|
|
|
MFC will be with us for a long time. There is so many apps out there that rely on MFC that Microsoft wouldn't want to risk removing support for MFC.
I'm not 100% sure that MFC will be updated very much in the future. I don't think there are many more changes that Microsoft can make. MFC pretty much does all it can for writing Win32 platform applications.
The question mark is on what framework will C++ programmers be using to write .NET applications. (I'm not even sure Microsoft have an answer to that yet)
Michael
|
|
|
|
|
More headaches from everyone's favorite dev system.
When I click Add Resource, the program saves the open files and then exits. !!!
I've tried this on several projects, it only happens on 2 of the 4 I tried. Both are largish projects ported from VC6. The two it works on have minimal RC files (version info only). I checked with my boss; same thing happens on his machine.
And to add insult to injury.. the usability experts at Microsoft removed the "Open as Text" option for files, so I can't even add the resource manually, without leaving VC.
Anyone else get bitten by this? Know of a solution?
|
|
|
|
|
More headaches from everyone's favorite dev system.
Reading posts at CP and in newsgroups, are you really sure MSVC7 is "everyone's favorite dev system"? ;->
If I could choose I'd rather have VC4.2 with the VC6 .dsp files (somewhat tweaked) and and up to date compiler. Most definitely also the VC4.2 MVB MSDN viewer that kicked the pants off the HTML based crap (in comparison) we have now.
|
|
|
|
|
Open as text is still there.
I have also had problems with the resource editor. Maybe we will get a patch soon.
....
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
Open as text is still there.
You're right! They sure did hide it well.
It seems that the VC++ team must have had a mandate to make every feature twice as hard to use... I haven't found anything in this version that is an improvement (other than the improved STL, of course).
|
|
|
|
|
Hello all,
What in your collective opinions would be the best way to recursively search a users's hard drive for files given that there are multiple files to search for and all this needs to be done in one operation?
I can use CFileFind to search the HD for 1 file, then re-do the search again for file 2, and so on and so forth, but...this could take years on large HD's...or is this the way to go?
Anyone, anyone, Bueller?
Frank
|
|
|
|
|
Just FindFirstFile & co. and do the regexp'ing yourself from the returned filenames.
|
|
|
|
|
Eureka!!! The eagle has landed.
Thanks, Mike. Sometimes you just need a little input to get you going back in the right direction again.
Again, many thanks.
Frank
|
|
|
|
|
Hi,
I am trying to use the MFC socket classes in a client/server app I am working with. How can I determine when a CSocket has data to be read, and I can call Receive? I am waiting for messages from a client on this socket. I do not want to use a windows message (AsyncSelect), but I find no EventSelect method in the CAsyncSocket class to parallel the WSAEventSelect function.
I tried using WSAEventSelect driectly, with the SOCKET handle encapsulated by the CAsyncSocket class, but ran into struct redefinitions and other include problems, because I was including both afxsock.h and winsock2.h, but if winsock2.h is not included, all of the WSA??? stuff is undefined. Has anyone tried something similar? I would like to have the flexibility of the raw WSA functions, with the encapsulation of the MFC socket classes. It seems MS chose not to wrap all of the winsock API in MFC, but seems like they intend these to be used with the CSocket/CAsycnSocket classes, since the socket handle is accessible to client code.
Thanks,
Aaron
|
|
|
|
|
This is not too elegant a solution, but you can try adding a CEvent member to your CAsyncSocket -derived class and signalling it in OnReceive .
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Not quite, but thanks for the advice. Actually, I am trying to use raw winsock functions with the MFC socket classes, but the includes are messing me up.
Anyone else done something like this? I had originally started out writing my own wrapper class for the socket functions, but thought it would be better to use MFC's classes if possible.
|
|
|
|