Re: Win32 or MFC - C / C++ / MFC Discussion Boards

bob coppock5-Feb-02 7:57

5-Feb-02 7:57

It just growed like Topsy. We are testing out a complicated piece of hardware with many motors, lasers, an FPGA, etc, with many things happening at once which need to be reported.

I can break the dialog in half, of course. In fact, I'm starting to do that, but it would be nice not to have to move so much code. The present dialog box .cpp file is already about 5K lines.

bob c

Re: Lots of controls in a dialog

Ernest Laurentin5-Feb-02 8:33

Ernest Laurentin

5-Feb-02 8:33

bob coppock wrote:
The present dialog box .cpp file is already about 5K lines.
Ouch!
If *possible*, create child Dialog(s) and insert them into your
dialog. Of course, your child dialog won't have any title bar, ok or/and cancel button.
Good luck,

- Dirty hands lead to important discovery...

Re: Lots of controls in a dialog

Michael Dunn5-Feb-02 8:11

Michael Dunn

5-Feb-02 8:11

There's a limit on the # of controls you can have in a DIALOG section in your .rc file. Additional controls must be created at runtime.

--Mike--
"Everyone has figured out what 'service pack' really means, so they had to go and change the language. Perhaps this is what Bill was talking about in the 'security is top priority' letter."
-- Daniel Ferguson, 1/31/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.

Re: Lots of controls in a dialog

Ravi Bhavnani5-Feb-02 8:53

Ravi Bhavnani

5-Feb-02 8:53

Looks like you have a fundamental GUI design issue here.

/ravi

"There is always one more bug..."
ravib@ravib.com
http://www.ravib.com

Question about Wizards

RK_20005-Feb-02 6:21

RK_2000

5-Feb-02 6:21

I was looking at the article by Robert Pittenger "Windows 2000 Style Wizards" and was trying to give it a try. The article is located at:

http://www.codeproject.com/dialog/wizard2000.asp

I wanted to bypass his initial dialog and force things to start with the Wizard right from the beginning. So, in the "Wiz.cpp" file, I just made the following modification:

CMasterDlg dlg; //used to be CWizDlg dlg;
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();

I also moved the code that was in the OnInitDialog of CWizDlg to the OnInitDialog of CMasterDlg.

however, I have a couple of problems.

One is that eventhough the pages do seem to be created, they do not show up and the second one, which probably stems from the first one and the fact that the pages are not somehow probably attached, is that I get errors when I try to cancel or click any of the keys.

Could you help me out on this one and tell me what I am doing wrong?

thanks

Win32 or MFC

redneckCoder5-Feb-02 6:12

redneckCoder

5-Feb-02 6:12

Hey,
I'm going to be installing Visual C++ 6 on my computer today and I have a question. Up til now, I've been coding on LCC-Win32 that is C only and doesn't provide access to the MFC. Now that I have VC++ and can use the MFC, should I stick with Win32 or switch over to MFC. I know you have to code in C++ to use MFC while I am most comfortable with C. This one's a matter of personal preference I guess huh? I still would like to hear any recommendations from anyone. Thanks.

-AJ

I code, therefore I am

Re: Win32 or MFC

Jon Sagara5-Feb-02 6:30

Jon Sagara

5-Feb-02 6:30

Get comfortable with C++, then learn MFC. Since you know the Win32 API already, picking up MFC should be a snap once you are familiar enough with C++.

Jon Sagara

What about ?

Re: Win32 or MFC

Ravi Bhavnani5-Feb-02 6:55

Ravi Bhavnani

5-Feb-02 6:55

Using C++ and MFC will make it easier to produce bug-free code faster. You're much better using C++ and MFC. Imho, learning C++ will take more effort than learning MFC. You should understand OOP before using MFC.

/ravi

"There is always one more bug..."
ravib@ravib.com
http://www.ravib.com

Re: Win32 or MFC

redneckCoder5-Feb-02 7:33

redneckCoder

5-Feb-02 7:33

I know both languages pretty well, so it's not a matter of learning C++. It looks, though, like the consensus is to use MFC because it's easier and more efficient. I'll try it out for a while and see what happens, if I don't like it I'll switch back to the API. Thanks for the opinions and advice.

-AJ

I code, therefore I am

Re: Win32 or MFC

alex.barylski5-Feb-02 14:16

alex.barylski

5-Feb-02 14:16

redneckCoder wrote:
like the consensus is to use MFC because it's easier and more efficient.

compiled code is fatter, than straight SDK, but as far as time efficiency, BIG TIME SAVER!!!

One you know all the ins and outs of MFC window programming isn't the same. You'll find you'll get stomped by errors you may NOT understand at first CUZ MFC uses ASSERT quite frequently which when programming w/ SDK doesn't concern you really, cuz you know exactly whats going on all the time.

redneckCoder wrote:
if I don't like it I'll switch back to the API. Thanks for the opinions and advice.

You won't like it at first cuz you'll have a natural tendency to stick with what you know well SDK is easy to follow and concise. However like i said once you MFC...it's great time saver.

Splitter windows i found to be a pain in SDK, MFC...nothing at all...

Give MFC a real chance, you won't regret it

Poke tongue | ;-P

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

CToolBar default position and destruction

5-Feb-02 5:46

Hi,

can anyone tell me how to avoid the stacking effect that occurs when I load toolbars at application startup? I want them to be aligned horizontally. Is this possible?

Also, when I programatically nuke a CControlBar when I close a document the background appears to remain. I've tried calling DestroyWindow() on the control bar before I delete it, but this does not work. What's the correct way to tidy things up?

Any help appreciated

thanks

matthew

Another String Question

Tom Wright5-Feb-02 4:33

Tom Wright

5-Feb-02 4:33

I've noticed that sometime upon exiting my program, it errors out with a "memory could not be read". While debugging I see that my string buffers are not reseting themselves. How can I go about clearing my buffers out so that I do not get this error. Or am I looking in the wrong place. I still am curious as to how I go about resetting my buffers each time........

Please be patient with me as I am a cobol programmer (but I understand C++) and in cobol you must initialize your buffers so that left over data does not stay put.

Thanks again

Tom Wright
tawright915@yahoo.com

Re: Another String Question

Jon Hulatt5-Feb-02 4:52

Jon Hulatt

5-Feb-02 4:52

every sting that you allocate (or in fact any data type) in this way....

CString *pString = new CString;

// or

char *pChar = new char[n];

must be deallocated when you're finished with it:

delete pString;

// or

delete pChar;

But, if you create vars like this:

CString myString="hello";

// or

char myChar[]="hello";

then you dont delete them; it's done for you when they go out of scope.

Jon

Sorry to dissapoint you all with my lack of a witty or poignant signature.

Re: Another String Question

Jamie Hale5-Feb-02 6:00

Jamie Hale

5-Feb-02 6:00

A relatively major correction...

If you allocate with:

char *pChar = new char[n];

you must deallocate with:

delete [] pChar;

otherwise you end up with leaks.

J

Re: Another String Question

Nemanja Trifunovic5-Feb-02 6:14

Nemanja Trifunovic

5-Feb-02 6:14

Jamie Hale wrote:
otherwise you end up with leaks.

No, you don't. delete[] differs from delete because it calls destructors for all the objects in an array. For "built-in" type, you have no destructors and it does not make a difference.

However, it is still a good programming practice to use delete[] for all arrays allocated with new[]

I vote pro drink Beer | [beer]

Re: Another String Question

Joaquín M López Muñoz5-Feb-02 6:25

Joaquín M López Muñoz

5-Feb-02 6:25

No, you don't. delete[] differs from delete because it calls destructors for all the objects in an array. For "built-in" type, you have no destructors and it does not make a difference.

IMHO it does make a difference. When allocating an array with new[], the compiler must reserve an extra bit to recall how many elements there are in the array. Typically, this extra info is allocated at the beginning of the block, and the remaining portion is what's returned to the user. When delete[] is called, the compiler subtracts some bytes to the pointer passed by the user to access the size information. So, if delete is called instead, the compiler will request the underlying memory system to free a pointer that is off its original position by some bytes! Needles to say, this can make the app crash.
(Other schemes for storing the array size information exist, that do no suffer from this inconvenience; but generally speaking, calling delete on an array allocated by new[] is undefined behavior.)

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: Another String Question

Nemanja Trifunovic5-Feb-02 6:39

Nemanja Trifunovic

5-Feb-02 6:39

OK. Try this:

int main()
    {
    while (true)
        {
        int* a = new int[50000000];
    
        a[2] = 2;
        delete a;
        }
    }

I've found no memory leaks, and certanly no crashes.

However, as I already pointed out, delete[] is the way to go in all the cases we use new[].

I vote pro drink Beer | [beer]

Re: Another String Question

Tim Smith5-Feb-02 15:35

Tim Smith

5-Feb-02 15:35

WRONG!!!!

You MUST call delete [] when a buffer was allocated with new [].

Check 5.3.5.1, 5.3.5.2 (which specifically states that using delete on an array is undefined.), and 5.3.4.8.

Also 5.3.5.6 specifically states that the destructor will be called for non-array and array deletes. It is just the case with built-in types such as int, there are no destructors to be called.

It works out of luck. In earlier versions of VC, it would work in debug mode but not release.

Tim Smith
Descartes Systems Sciences, Inc.

Re: Another String Question

Nemanja Trifunovic6-Feb-02 6:11

Nemanja Trifunovic

6-Feb-02 6:11

Urgh!!!

Did you read my post? Mad | :mad:

Of course delete[] should be used after new[]. However, it WORKS (with VC 6.0 both debug and release) even without [], out of luck or not. It does not mean you should ever do this, but it works, and that's all I wanted to say.

I vote pro drink Beer | [beer]

Re: Another String Question

Tim Smith5-Feb-02 15:36

Tim Smith

5-Feb-02 15:36

You are right.

Check my message. It makes a HUGE difference since invoking 'delete' on an array is undefined. I have seen it crash in release builds many times.

Tim Smith
Descartes Systems Sciences, Inc.

Re: Another String Question

Jamie Hale5-Feb-02 14:41

Jamie Hale

5-Feb-02 14:41

Interesting. I was all ready to post wondering what the heck you were talking about, "calls destructors for all the objects in an array"... sounds like Java to me. But I double-checked and found you are indeed correct. Smile | :)

However, according to my copy of C++PL, "The effect of deleting an array with the plain delete syntax is undefined, as is deleting an individual object with the delete[] syntax." So it sounds like Microsoft just decided to do it their own way. Jig | [Dance]

Re: Another String Question

Tim Smith5-Feb-02 15:39

Tim Smith

5-Feb-02 15:39

It works with MS out of luck. I have had many programs crash due to this error by the programmer, Smile | :)

with VC when in release mode.

Tim Smith
Descartes Systems Sciences, Inc.

Re: Another String Question

Nemanja Trifunovic6-Feb-02 6:16

Nemanja Trifunovic

6-Feb-02 6:16

Jamie Hale wrote:
Interesting. I was all ready to post wondering what the heck you were talking about, "calls destructors for all the objects in an array"... sounds like Java to me. But I double-checked and found you are indeed correct.

However, according to my copy of C++PL, "The effect of deleting an array with the plain delete syntax is undefined, as is deleting an individual object with the delete[] syntax." So it sounds like Microsoft just decided to do it their own way.

Exactly. Maybe there are too many programmers who forget [] Poke tongue | ;-P

I vote pro drink Beer | [beer]

Re: Another String Question

Tim Smith5-Feb-02 15:38

Tim Smith

5-Feb-02 15:38

First, clean up your lack of deallocations as others have stated. However, the bad news is that there is little chance doing that will fix the problem.

But, maybe by freeing up the memory, those strings will be forced to trash values while in debug mode and it might help you find the problem.

Tim Smith
Descartes Systems Sciences, Inc.

Re: Another String Question

Tom Wright6-Feb-02 5:48

Tom Wright

6-Feb-02 5:48

So I guess the question is. Why would I want to bother setting and deleting a pointer to an address space, which is storing characters, when I could let the operating system do this for me by just setting the my char variables like this

char StringBuf[32400];

I mean basically if I look at the class for CString.......won't I see that it is setting my StringBuf to a char array with a variable size?

Tom Wright
tawright915@yahoo.com

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.