Some questions regarding my project

[Tusike]

Hi!
I'm currently working on a small program that helps me learn words in different languages.
I wanted to complete the whole thing and then ask some questions, but the problems I'm having are a bit annoying and I'd like to take care of them before I continue.

Here's the program so far: http://www.mediafire.com/?7yt723jcly14mr8

My main questions are the following:
-How can I have a nice transition from one screen to another? The user should only notice things inside the window changing, not a whole new window emerging.
-How can I get rid of the sound the program makes when the user presses ENTER?

And some other things that aren't vital now:
-How can I detect left or right mouse doubleclicks in a listbox event?
-I'm not sure if I'm taking care of memory correctly.

I used #### signs to mark where these issues are in my program in the files form1.h, lists.h & .cpp, form2.h & .cpp. The number of ### signs shows the importance of the problem, so you'll most likely notice the most important ones

The main problems should be pretty clear if you give the program a try.
I didn't encounter any fatal errors, but here as some guidelines to minimize the probability of the program crashing:
-The options whether to ask words randomly or in order; in what language to ask them; what to do if the answer is wrong; and the number of repetitions should work, i haven't implemented the other features yet.
-On the left side a list of words titled "Magyar-Német Állatok I." should appear. Double clicking this opens a new form where you are asked words. If you don't want to learn them, make sure "If answer is wrong: wait for keypress" is selected; then you can just skip the questions by pressing ENTER (this will be good for a quick review of words).

Planned features:
-The ones shown in the options menu but aren't working yet.
-The ability to create/delete lists
-The ability to edit lists: add words, delete words, edit words (add meanings, questions, answers, etc..)
*this is where detecting a mouse double-right click would be nice - left click starts asking a list, right click edits the list.
*So far you manually have to edit the *.list file you want to use

I'm sorry for the long post, I tried to be as to the point as possible. But I did want to give a pretty complete picture of the program, I find that usually makes it much easier for people to help

Thanks to anyone who checks it out and can give me some advice!

-Tusike

[S_M_A]

Post the code here instead of at some external site.

[Tusike]

Sorry, I didn't know I can post files here as well; I don't know if there's anything wrong with mediafire though.

Here's the program: learnlang.zip

Due to the 500kB limit, this contains only the main files of the program. The precompiled header and everything else Visual C++ generated on its own are in the mediafire link.

[S_M_A]

Most people here doesn't like going to another site and maybe getting spammed with popups.

[Eri523]

Most people here doesn't like going to another site and maybe getting spammed with popups.

The new one from post #3 is a CodeGuru attachment, inlined, as is possible since the forum software update.

Didn't have the time to inspect it yet, though.

[S_M_A]

I know that. My comment was a reply to

I don't know if there's anything wrong with mediafire though

[Tusike]

So.. Do any of you know what I can do? Or where else can I ask?

[Eri523]

-How can I have a nice transition from one screen to another? The user should only notice things inside the window changing, not a whole new window emerging.

The mere fact that you feel the need to ask this question may indicate a fundamental GUI design issue with your program. Ask yourself: Do you really need the second form?

Hard to judge for me without actually seeing your program. The best impression can, of course, be acquired by seeing the program in action (see the end of the post), but some strategically taken screen shots may also do for starters.

Generally, interaction between two forms actually isn't a subject that's asked and discussed in here too rarely. Unfortunately the forum search is still out of order, but probably any thread having "two forms" or something like "form-to-form-communication" in its title is related and may give you some inspiration. Just scroll a bit back in time in the thread listing.

-How can I get rid of the sound the program makes when the user presses ENTER?

It looks like anything you're doing in textBox1_KeyPress() would be better done in a TextChanged handler. That way you wouldn't need to mess around with keyboard input any more which certainly is the reason for that noise.

Actually, there's quite rarely a need to handle the KeyPress event at all, while TextChanged probably is the most-handled text box event of them all. And even if you actually do need a KeyPress handler you should clean it up and do anything possible in a TextChanged handler.

-How can I detect left or right mouse doubleclicks in a listbox event?

Like any other control, the list box has a MouseDoubleClick event. The event handler gets passed the mouse position and you can use IndexFromPoint() to determine which item is under the mouse. You may also consider the list view as an alternative control: Its ItemActivate event IMO provides a more natural way of reacting to double clicks.

All the above won't catch a right double click, though. And I don't know of any framework or other library implementation of that. Of course you can implement that yourself, but that would be tideous and, honestly, do you really want to demand from your users to learn that? If you want to provide multiple functions for the right mouse button, do it like all the other apps do it too: Use a context menu. (Perhaps a right click plus modifier key, like shift, can be an alternative, but IMO users are more familiar with context menus. Just no double click, please...)

-I'm not sure if I'm taking care of memory correctly.

The general answer is: This is .NET, so don't worry. While resource leaks aren't completely impossible there either (though IMO mostly that won't be memory leaks then), this is the exception from the rule and MS strives to document them (they probably missed a few, but I didn't catch one of those yet). Here's an example of a documented one: The System::Windows::Timer is not subject to garbage collection unless you stop it before disposing the containing object (a form in most cases, probably). They tucked away that caveat into the documentation of one of its properties instead of putting it into the documentation of the class itself. And unfortunately the functionality of that property is so obvious that many developers probably won't ever look there...

The more specific answer, though: You're mixing C++/CLI (i.e. .NET) with a bit of C++ standard library (i.e. native) in your code. Of course that native stuff may cause the usual memory leaks if not used properly. This sort of mixture shouldn't be used unless there's a really good reason to do so (and just convenience is none of them ). I didn't look really thoroughly, but AFAICT all the standard library stuff you used is pretty much covered by .NET framework alternatives.

I'm sorry for the long post, I tried to be as to the point as possible. But I did want to give a pretty complete picture of the program, I find that usually makes it much easier for people to help

I'd suggest not to worry about that. Your post is not too long (compare it to mine... ) and decently on-topic.

Unfortunatly, your ZIP file attached to post #3 did give some insight into your code, but it didn't make up a compilable project. Instructions for uploading complete projects:

• Do a clean-up (in the Build menu) on your project in the VS IDE. If you mabe both debug and release builds of the project, you'll need to do two clean-ups as well. Just select each build type as if you were building and instruct the IDE to clean up.
• Manually delete the .sdf file from the solution directory (the one with the .sln file in it). The file is not subject to project clean-up, can become quite bulky (see below) and will automatically be rebuilt by the IDE in the background when required anyway.
• Without starting the IDE in the meantime (it would rebuild the .sdf file), zip the solution directory and upload the result.

As per my experience, the .sdf file is bloated by more than one magnitude just by referencing the Win32 API or the native C++ standard library. That way the file can easily become 25 MB and more. Personally, I have never used .NET plus standard C++ library but no Win32 API in a single solution, but according to your description of the first attempt to upload the zipped project and from how I overlook what I know of your project, that seems to have the same effect.

[Tusike]

Your post is not too long (compare it to mine...

True, but seeing as I'm the one seeking an answer, I'm only grateful for that.

I did a clean-up and everything; last time I figured out that I can delete the *.sdf, but I wasn't sure how I could get rid of the precompiled header (4Mb). The clean-up took care of that, so I hope this one will work:

learnlang2.zip

Do you really need the second form?

A few weeks ago I asked in the Visual C++ forum how to handle changing screens, and the answer was that I should use multiple forms (along with that I should have posted in this forum). First I tried working with multiple panels, and always toggling their visibility to change the screen, but that didn't really work out.
And yes, I hope that my need to do this, (or a better explanation of what else I could've done), will be clear from the program.

It looks like anything you're doing in textBox1_KeyPress() would be better done in a TextChanged handler.

Well, I didn't try it out, but seeing as pressing ENTER doesn't change what's in the textbox, this didn't occur to me. We'll see if it works.

Just no double click, please...

I agree. I made this program in Freebasic 2 years ago, where I didn't implement the mouse. UP/DOWN changed the selected list, ENTER started to ask a list, and E started to edit the list. Now, since double clicking starts asking the list, the first idea that occurred to me was for right double clicking to edit the list. The context menu idea is better because I also need a way to delete the list, and add a new list, so I can just add those options to the context menu.

As for the memory problems, the truth is right now I don't care that much, I'm trying my best to make sure everything is handled correctly & marking where I'm not sure. If there is an error, I think that (probably) I will encounter it while using the program, in which case I can go back, find it, and fix it. I once had a pretty tricky memory error in a towerdefense game; sometimes it crashed after 7 minutes of playtime, or 15, or I went through a whole 45 minute game without it crashing; and I found it! So once encountered, I hope I'll be able to fix it

-Tusike

[Eri523]

I did a clean-up and everything; last time I figured out that I can delete the *.sdf, but I wasn't sure how I could get rid of the precompiled header (4Mb). The clean-up took care of that, so I hope this one will work:

[...]

AFAIK the .pch file will be rebuilt when doing a project build next time (how else could the clean-up simply delete it?), but I didn't really care ever, since, as you stated correctly, the project clean-up takes care of that. I downloaded your file but didn't look inside yet. At least the size looks reasonable.

A few weeks ago I asked in the Visual C++ forum how to handle changing screens, and the answer was that I should use multiple forms (along with that I should have posted in this forum). First I tried working with multiple panels, and always toggling their visibility to change the screen, but that didn't really work out.
And yes, I hope that my need to do this, (or a better explanation of what else I could've done), will be clear from the program.

Can you post a link to that thread (you know, that forum search thing... )? That may provide useful extra information about your project. From what I know by now about your program, panels may definitely be worth consideration. They're sort of a "form on a form", without a visible border, though.

Well, I didn't try it out, but seeing as pressing ENTER doesn't change what's in the textbox, this didn't occur to me. We'll see if it works.

If you don't want the Enter key to directly influence a text box you either simply don't make it multi-line or set its AcceptsReturn property to false. A quick check seems to indicate that the latter may not work as expected if the form hosting the text box does not have a default button (AcceptButton), but there's certainly somethinbg else that can be done about it instead of using a KeyPress handler.

As for the memory problems, the truth is right now I don't care that much, I'm trying my best to make sure everything is handled correctly & marking where I'm not sure. If there is an error, I think that (probably) I will encounter it while using the program, in which case I can go back, find it, and fix it. I once had a pretty tricky memory error in a towerdefense game; sometimes it crashed after 7 minutes of playtime, or 15, or I went through a whole 45 minute game without it crashing; and I found it! So once encountered, I hope I'll be able to fix it

This approach isn't fundamentally different from the way I, and probably many others, write their programs. But by simply not diong things that are known to not be a good idea in the first place, many problems can be prevented up-front.

[Tusike]

Link to the thread:

http://forums.codeguru.com/showthrea...Multiple-pages

That may provide useful extra information about your project.

I really don't think it will; or at least minimal information as opposed to, say, opening my project...

[Eri523]

Link to the thread:

[...]

I really don't think it will; or at least minimal information as opposed to, say, opening my project...

Well, I don't quite agree. Let's look at your very first post in that thread:

I'm currently working on a program that will help me study languages by asking words from a list. What I need is a way to change what's on my Form - there's a different screen in the beginning, then when the program's asking question, another for editing the words in each lists, etc...

How can I change what the user sees, while still working with one Form?

Given that description, to me it looks like a great opportunity to use tabs.

And in fact you seem to already have abandoned the idea of using individual forms in post #3, slightly more than one month ago:

[...] I'm interested in how I can change what's on my window using Visual C++. It's hard to imagine that it's designed to only have a static look... Right now my newest idea was to use these "Panels", each representing a "screen", and then just toggle the panels' visibility and enabled property on and off. Is that the best option available? Using multiple forms seems really weird to me, why would I need more than one window to run my program in? [...]

Finally:

Actually, what you described looks to me like a sort of wizard. User does some action/settings with one view and then gets to another view, and another view, etc. In regular programming practice it's typically done by tabbed dialog (a main dialog with tab control on top of it) or wizar-like dialog (a dialog with Back/Next/Finish buttons in the bottom area). Both apps use borderless child dialogs with a single dialog visible at particular moment, which visibility is controlled by either tab control or Back/Next buttons. All logic about processing user input is implemented in particular dialog (procedure or class), and main dialog may provide a menu/toolbar handling (or may not, as MFC internally implements command routing mechanism)

Although parts of this paragraph, in particular the end, are rather MFC/Win32-specific, Igor already alluded to the basic idea of using tabs here. And a wizard-style dialog basically is a tabbed dialog without tabs. While tabbed dialogs are natively supported by Windows Forms, wizards are not. There has been a discussion about how to implement them nonetheless here some time ago, and the conclusion was that the best way of doing that probably is using a tabbed dialog but pushing the tabs out of sight. (The idea of using panels was considered too, but eventually abandoned.)

One thing you seem definitely need to get rid of is the Freebasic way of thinking. I don't know Freebasic myself, but from your description it looks like while it does support graphic elements, the Freebasic programs work more like a console application. And that's simply not the way GUI apps are written, even less so nowadays.

[Tusike]

the best way of doing that probably is using a tabbed dialog but pushing the tabs out of sight.

and that is what for some reason didn't even occur to me. I threw out the tab idea right away thinking that I didn't need those tab things showing, and concentrated on the other two possibilities.

Also, switching the textbox to multiline fixed my problem with the sound! And, since after pressing ENTER I already reset the textbox's Text to nothing / zero-string, it really doesn't matter whether more lines would be possible or not. Plus using the KeyPressEventHandler remained working fine.

Many thanks for all your help so far, I feel I'm good to go! I'll post here if I run into any other problems, but I hope I won't.

-Tusike

[Eri523]

and that is what for some reason didn't even occur to me. I threw out the tab idea right away thinking that I didn't need those tab things showing, and concentrated on the other two possibilities.

Unfortunately forum search still doesn't work, so I tried to locate the thread using my attachment list, yet to no avail. I know I posted sample code there, but apparently as a code snippet, not a complete demo project (though I had one here to play with). If I had found it, I'd have posted a link here for you.

Also, switching the textbox to multiline fixed my problem with the sound! And, since after pressing ENTER I already reset the textbox's Text to nothing / zero-string, it really doesn't matter whether more lines would be possible or not. Plus using the KeyPressEventHandler remained working fine.

Actually, this is not what I had in mind; I thought, for instance, the text box already were multi-line and that might at least indirectly contribute to the problem. And I still think using a KeyPress handler without a compelling reason unnecessarily complicates things. But hey... it works!

Many thanks for all your help so far, I feel I'm good to go! I'll post here if I run into any other problems, but I hope I won't.

You're welcome!

[Tusike]

OK, I'm still having problems with the sound when pressing ENTER.

I tried using TextChanged handler, but I don't know how to detect whether ENTER was pressed in that.

Right now, here's the behavior of the textbox:

-If it's not multiline, it works perfectly, except for the sound.

-If it is multiline, there's no sound when pressing enter, and that's good.
The program starts by asking a word - "Dog". I enter "der Hund" + ENTER, it is correct, the program continues.
Then the program asks the next word - "Cat". I enter "die Katze" + ENTER - the program thinks it is false, displays the correct (but same) answer, and asks again. No matter how many times I enter the correct answer, the program thinks it is false.
However, if I press BACKSPACE before typing anything in the textbox, then type "die Katze" + ENTER, it is accepted and the next word is asked...

That seemed pretty weird to me. But it gets worse... I thought perhaps because of the multiline, chr(13) is somehow added to the textbox's text when I press enter (even though for each new word & mistaken word, I always reset textBox->Text = ""). So entered "die Katze" 10 times in a row, each time getting asked again, and then I inserted a breakpoint in my code where the answer was checked, and viewed textBox->Text's value. The debugger showed "die Katze", so I continued - and my answer was accepted....

So basically, if I put in a breakpoint there in my code and press F5, the answer is accepted, otherwise not. I'm completely lost.