Well, blast. My first attempt took too long, and I autodisconnected.

Short version:

Not doing homework, on internship(first gainful employment).
Task: Make GUI for existing Console app that takes binary input file.

Milestone: By Monday, create windows App that displays output of binary and text input files using MFC.

Assumptions:
Document/View Architecture optimal means to achive goal.
Not ready to attempt serialization yet.
Goal can be reached through parsing the input and creating multiple views based on single document, thus SDI is appropriate.


Current Status:
Annoyed.
Have gone through crashcourse on C/C++ over last week and a half, understand the console App, have spent at least 60 hours going through online MFC tutorials, reading MSDN.net stuff, line-by-line study of MSDN samples.

Questions:
1. The Document should logically be location where file I/O and parsing occurs, and the View should be where text is output to screen, right?

2. Why can't I just have a custom Override of CFileDialog residing in the CWinApp (in the project application) message map tell the document class that there's parsing to be done?

3. Why does a book I bought yesterday suggest that file I/O should be done in the View class?

4. I know that the ON_COMMAND message routing from view goes to the document as well if unresolved in view. Is that the proper solution?

Thanks in advance (and ctrl+c'ing this time...)
-Drowzee1

EDIT:

I have just found that I can call CFileDialog as part of my Document. While that makes me very happy, I can confidently say that I've no clue if that's appropriate or not. I think I should modify the BOOL OnOpenDocument reinitializer to do something in this case...

It's quite all right if MFC isn't really familiar to anyone, by the way. I've seen notes saying that MFC was dropped in favor of Visual Basic... A pity, but I can understand the reasoning of 'It was too complex for most programmers'.

I certainly feel it is.

Heh.

Thanks anyway to those who thought about it even a little.

>It's quite all right if MFC isn't really familiar to anyone, by the way.
Thanks for assuming that we're all ignorant just because your question wasn't promptly answered to your satisfaction. Technically, this forum is for C and C++ language issues, and non-standard library questions should be directed elsewhere. However, since there isn't a good elsewhere on Daniweb, if you wait long enough, somebody will get bored and look into answering your question.

>I've seen notes saying that MFC was dropped in favor of Visual Basic
MFC was dropped in favor of .NET. But, since MFC was just a poorly designed wrapper for the Win32 API, only diehard C++ programmers who just had to use classes and weren't willing to learn Win32, used it enough to get good at it. Everyone else just did what had to be done and tried to forget.

You can find those diehards lurking around here. That's the best elsewhere I can think of.

My apologies. I merely meant to say that, as I had found relatively little support/documentation to assist a newbie in MFC, I did not have high expectations for a response. It seems like no one in the company really understands MFC either, so I've been pretty much on my own for getting things working.

I have been a bit anxious over this, and my original post (the first version) was far more descriptive and not as terse/gruff.

Thank you for the link. I have never heard of google groups before, but that link appears to be a much more appropriate venue for my questions.

I'm sorry I came across as condescending. I just don't have much time left to me, and I do want to make a good impression at my first actual paying job.

I suppose that's really no different than getting help with homework; Just different grading methods.

Hopefully I'll be able to contribute to this forum soon, instead of delivering backhanded insults.

Thanks.

>Hopefully I'll be able to contribute to this forum soon
I look forward to it. We're always happy to have new helpers...and new helpees, because without the helpees the helpers get bored and leave.

"MFC was dropped in favor of .NET. But, since MFC was just a poorly designed wrapper for the Win32 API, only diehard C++ programmers who just had to use classes and weren't willing to learn Win32, used it enough to get good at it. Everyone else just did what had to be done and tried to forget."

So worried was I about the first part of the response, I just caught the implication of this.

Face, meet desk. Desk's a little hard of hearing, so you'll probably have to introduce yourself... loudly... several times.

I wonder if I can convince the team to let me learn something more recent, then. What you say worries me, particularly when I consider that this program is supposed to be scalable [by another poor schmuck] after my internship is over. I don't want to make something that will be obsolete even if it's just to display text...

... And I spent 60 bucks getting a tutorial book, too... Oh, well.

Only problem is that I don't think they've got .net here. But if I'm convincing enough, perhaps I can change that.

It gets worse. Avalon promises to phase out .NET as soon as Longhorn comes out, so while you have a bunch of people scrambling to learn .NET, others are wary about learning something that might turn out to be useless in the next year or so.

I'm running out of desks to break here, Narue...

But there is MUCH more support for .Net; I've seen gobs of manuals in the bookstores. So as long as Longhorn SUPPORTS .Net (and as this terminal, at least, runs on Windows 2000... but that's not a sure sign that they won't upgrade), it should still work, right? ...Right?...right?

... I should probably find out what .Net's benefits and detriments are first... and C#. When my overlords get back on monday, I need to get them together to discuss this whole mess... Got any suggestions on what'd be the easiest-to-expand-upon language?

I mean: if you wrote a windows-base program correctly in the language, what language would be the easiest for someone else with little or no prior experience in that language (except for c/c++ background) to pick up and start adding more features?

>it should still work, right? ...Right?...right?
Right. In theory.

>Got any suggestions on what'd be the easiest-to-expand-upon language?
It depends on the program. Win32 still works across the board, and I don't imagine .NET being completely unsupported for a long time. I would say Java is your best bet for something guaranteed to work (since Windows isn't likely to kill support for the JRT), but there's nothing wrong with using Win32, MFC, or .NET until we know for sure that there will be problems. Of course, all three of those are convoluted and a real bitch to work with, but .NET is the least evil, and the easiest to grasp for a newcomer. Especially since a newcomer is likely to know Java, and C# is similar to Java.

Well, I'll do some research this weekend. I can't make a pitch without something to back it up; I'm pretty good at bs'ing, but not THAT good.
Or maybe I'll get lucky and MFC will suddenly make sense in the next... say... three hours. Heh. I'll take care of it one way or another. Thanks!