CToolBar default position and destruction - C / C++ / MFC Discussion Boards

Ravi Bhavnani5-Feb-02 8:53

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

not printing!

5-Feb-02 4:34

for ( numOfLines =0; numOfLines < 15; numOfLines ++)
{
cin>>tempCN>>tempST>>tempMT>>tempTM>>tempIV>>tempNS;
(*tempStock).setCompanyName(tempCN);
(*tempStock).setStockTicker(tempST);
(*tempStock).setMarketTraded(tempMT);
(*tempStock).setTypeOfManufactr(tempTM);
(*tempStock).setInitialValue(tempIV);
(*tempStock).setNumOfOutShares(tempNS);
cout<< (*tempStock).getCompanyName()<<" "<< (*tempStock).getStockTicker()<<" " <<(*tempStock).getMarketTraded()<<" " <<(*tempStock).getTypeOfManufactr()<<" "<< (*tempStock).getInitialValue()<<" "<<(*tempStock).getNumOfOutShares()<< endl; Cry | :((

this piece of code prints all those elements but the 4th one,
any ideas why
thank you

Re: not printing!

Jon Hulatt5-Feb-02 4:48

Jon Hulatt

5-Feb-02 4:48

Step 1. Do not mail me directly with a request, post it here. Thats just rude. What if I was on the toilet or something.

Step 2. Lose the (*tempStock). thing. if tempStock is a class pointer, then get to its members by referencing them like this: tempStock->setCompanyName .

Step 3. Use the debugger. I would think that either one of your set* functions or one of your get* functions is screwed. trace through, step by step, and see where the data goes missing.

Step 4. If, and only if, you are still stuck, having tried tracing through with the debugger, then provide enough information for people to help you. To me, "4th Element" is one before a crap film. Which element? is it tempTM & setTypeOfManufactr???? if it is, say so. Also, it'd probably be useful to actually post the code for the set and get functions in question.

Remember to post your code inside of <PRE> ... </PRE> tags, so that formatting is preserved.

Jon

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

USB Communications

Paresh Solanki5-Feb-02 4:25

Paresh Solanki

5-Feb-02 4:25

How do you do this sort of thing?

I have two projects in mind.

1) write a better xfer program for my MP3 player than the one supplied with it
2) talk to devices of my own design via the USB

What I would like to know is how does one go about chatting to a device on the USB port.

Are there any utilities that can monitor the data that is transferred on the USB?
I want to know what the xfer program sends and recieves from the MP3 player.

Paresh Solanki
One Tequila Two Tequila Three Tequila Floor
five Tequila, six Tequila seven Tequila more

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