|
I'm the person who started the string below called "where's main() ???".
Ravi was helping me but either has given up on me or gone to bed 
So, here's my question: If I create a dialog window and want to run
graphics in it continuously, where do I put my code that does the
graphics? I'm not using messages, the application is free-running.
I would guess I'm not the first person to ever wonder "Gee, I wonder
where my application goes?" but none of my 4 books tell me and no
one else has been able to tell me. Having just finished my C++ class,
this is my first and foremost question -- where does the code go now
that I'm no longer running console-only apps?
I've spent all day trying to figure this out, including numerous and
fruitless web searches. I presume the place where the application
code goes is well-defined and well-known, can someone tell me?
Thanks.
Dave
|
|
|
|
|
Well mate, i had a similar problem when i moved from dos based programing to windows type programming....
In windows you have created a dialog app, so you do need to responde to messages to get you job done effectivly, else i can only say that your code will become very inefficient.
You cant have a continouse loop waiting for the keypress by the user to terminate the application....like we did in dos programs.
the loop is there but it is called as the message loop. you can add your code in the message pump loop, but still again its inefficient.
You can setup a timer and respond to the timer every now n then. or you can handle the OnIdle event to do things that you would like to do. but you should not lock up that event,i.e return back as soon as possible.
Summury:You need to change the design of your application when making a moveing to windows.
hope i helped you someway.
regards
Prakash.
The World is getting smaller and so are the people.
|
|
|
|
|
Prakash,
Thank you very much for your suggestions. Sorry it took
so long to get back to you but I had to do some quick
reading of timers and the OnIdle event. I think one
of these will work for me and I appreciate your help.
I'm willing to change the design of my application, I
just didn't understand the need to until your reply.
Thanks again!
Dave
|
|
|
|
|
No Problem, nice to know that it helped and appreciating it.
regards.
The World is getting smaller and so are the people.
|
|
|
|
|
|
The latest book by Charles Petzold is a good starting point for Windows programs. I started with his Windows v3.1 book. It was a wonderful learning experience. I also used a few books by Herbert Schildt. They were fun!
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hi, I'll try to help you out as it kinda seems to me everyone else hasn't really answered your question fully.
First off there's two main ways to go about programming Windows. There's the MFC and the Win32 API. MFC is Microsoft's wrapper classes around the Win32 API. MFC in a nutshell is Win32 with the details hidden from you, i.e. you use Microsoft's functions which in turn access the Win32 API.
I use MFC, so my knowledge of Win32 is vague, but in Win32 the application starts off in the WinMain() function. In MFC you can't see this, because its hidden behind the scenes. There really isn't a starting point that you can "see" in MFC. Your best bet as to understanding where an MFC app starts is by looking at the file projectname.cpp where the projectname is what you called the project. That's the first file thats used where you see any code.
Understanding the Win32 API will help you in using MFC, but its not necessary and from the little bit I've tried of Win32, there's a lot more stuff going on and takes longer to learn than MFC, I think. So I'd recommend starting off with MFC.
There's 3 different types of applications that you can make (as you've probably already seen in the wizard). Dialog based, SDI, or MDI. You should start off using the wizard and choosing either Dialog based or SDI to start off with.
There's a lot more to explain after that, but I don't want to write a book here unless I know I'm helping. I'd be happy to help you out though. Just send me a message and I'll explain more or if you really want help I could walk you through some examples over instant messenger if you wanted to.
|
|
|
|
|
Decided to continue my post since I didn't really mention what you were asking.
Anyway I recommend that first you start out by making a simple Dialog based MFC app using the wizard. I think this is the easiest thing to understand and its what I started out learning. You can immediately run the program and it will show you the default dialog that was created. Open up the file projectnameDlg.cpp (projectname is what you called the project). This is where you will be adding code. In a dialog window all the code that handles things displayed to the screen generally is done within the dialog's class. It can be done outside of it, but that's more advanced so I won't get into it.
Some main places that your code can go is in OnInitDialog() and in functions for each control. Its kinda hard to tell you how to do things here, so the only thing I can really tell you without walking you through an example, is to double click on the OK button in the resource and it will generate the function for when the button is clicked. This is an example of where you'd put code that you want to execute when the button is pressed.
Now for what you want to do, you'd be choosing an SDI application. To me an SDI makes more sense if you understand dialog based although many people will say its the other way around.
The way an SDI works is you paint things onto the screen. This is done in the ChildView using the OnPaint() function. That's where you can put code in order to draw things. Generally you won't be doing the drawing directly from OnPaint, but rather you'll be calling other functions you create to do something and then draw things from there. But for a simple example just to learn you can draw a circle directly in the OnPaint() function.
Hope this helps. Anyway like I said in my previous post I'm more than willing to walk through some examples with you. Helps me sharpen me skills  .
Mike
|
|
|
|
|
The following code works in VS 6 debug/release.
Works in debug in VS .NET, but locks up in release.
<br />
CString Desc;<br />
<br />
<br />
while ( fscanf (LoadFile, "%lf %lf %lf %lf %lf %d %[_0-9 a-zA-Z]", <br />
&m_dTemp, &m_dIce, &m_dWind, &m_dTension, &m_dK, &m_iCode, Desc) != EOF)<br />
{<br />
m_cboLoads.AddString( cDesc );<br />
}<br />
The fscanf is causing the lock up with the CString. Any ideas, or avenues of research?
thanks
|
|
|
|
|
Convert your program to C++ ?
Seriously, C file handling is SO ugly.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Yes, I have been putting that off.
What is best way to read formated text from a file with c++.
Example:
<br />
0.00 0.50 4.00 0.600 0.30 1 NESC Heavy<br />
32.00 0.50 0.00 0.000 0.00 0 32 Deg<br />
-20.00 0.00 0.00 0.000 0.00 0 Uplift<br />
60.00 0.00 0.00 0.350 0.00 1 Load<br />
60.00 0.00 0.00 0.250 0.00 2 No Wind<br />
60.00 0.00 0.00 0.000 0.00 2 CREEP CHECK<br />
90.00 0.00 0.00 0.000 0.00 0 90 Deg F<br />
120.00 0.00 0.00 0.000 0.00 0 120 Deg F<br />
167.00 0.00 0.00 0.000 0.00 0 167 Deg F<br />
212.00 0.00 0.00 0.000 0.00 0 212 Deg F<br />
302.00 0.00 0.00 0.000 0.00 0 HOT <br />
<br />
|
|
|
|
|
I'd use a struct so I could stream them in one go - read my article on iostream inserters and extrators. The problem would be that your string at the end is able to have a space in it. There are multiple ways to handle this, but the first that comes to mind is to read the floats in directly, as in
#include <fstream>
#include <string>
std::ifstream strm("c:\\my file.txt");
float a,b,c,d,e;
std::string suffix;
while (strm.good())
{
strm << a << b << c << d << e;
std::getline(strm, suffix);
// process each line here
}
that's off the top of my head, so not guarenteed to be production code, or even to compile You get the idea though.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
First of all i dont know how is this related to dot.net
Desc in has not been allocated any string..
so use it this way in the scanf
Desc.GetBuffer(20)
and after the scanf call Desc.ReleaseBuffer
this should work.
cheers.
The World is getting smaller and so are the people.
|
|
|
|
|
Because it works in version 6, it does not work in .NET.
I will try your suggestion as a fix until I get everything converted to c++. I am glad I know what was wrong though, thank you
|
|
|
|
|
Having just finished up a C++ programming class, I'm making the
move to MFC and Windows programming. I expected to find
something (at least roughly) equivalent to the main() routine
found in console apps. After looking through numerous books,
I still don't know where my application code goes. I know
how to do initialization (e.g. the OnDraw function) but I
don't know where I would put some code to make GDI calls.
I don't want to respond to messages (at least yet), I just
want to make some GDI calls in my main program.
Does someone know where the equivalent of main() is for
MFC programs?
Thanks. BTW, I'm not using AppWizard.
Dave
|
|
|
|
|
If you're using Win32 calls (instead of MFC), your Windows main() entry point is WinMain(). If you're using MFC, AppWizard will generate the application instance for you. The framework calls methods in your application, allowing you to implement/customize the app's startup. The real main() function is buried in the Windows startup stub that gets linked into your app.
> BTW, I'm not using AppWizard.
Aieee! I would strongly advise using the AppWizard. 
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Ravi,
Thanks for your input. Sounds like I should
use AppWizard. So I will. But I still don't
know where my application code goes. What are
the "application instances"? What is the
Windows startup stub? Can you help me with
the names of the classes that I should be
looking at? Are there some methods where
I would insert my application code?
Thanks again.
Dave
Dave
|
|
|
|
|
The class you want to look at is the one AppWizard derives from CWinApp, specifically the InitInstance() method. AppWizard peppers its generated code with comments which are reasonable helpful and will help you learn more about MFC's application framework.
I also suggest you look at some books on MFC/Windows programming to help you get started. I think you'll find the ones by Charles Petzold and Jeff Prosise to be a great read. You can likely buy them used for very little on EBay or Amazon.
And continue to post your Windows questions at CP!
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Ravi,
I have 4 books on Visual C++ 6.0 and/or MFC programming but
not the ones you mention, which I'll pursue getting.
I used AppWizard to create my program and looked at InitInstance()
and it seems to be only for initialization. The comment in the
code says "Standard initialization".
So, I still don't know where my application code goes. As noted
above, I'll pursue getting the books but is it possible, in the
meantime, to let me know where my "regular application code"
goes -- not the initialization code but the code that will run after
initialization?
My "regular application code" will display graphics on an ongoing
and continuous basis, I just don't know where to put it. Can you
let me know?
Thanks.
|
|
|
|
|
A Windows app that exposes a user interface requires a main window, and optionally various child windows depending on the type of interface (dialog, SD, MDI, etc.).
For your purpose, it seems that a dialog based app will suffice. The graphics will be displayed within the dialog box. When you run AppWizard (to create an MFC Windows Application), select "Dialog Based" at the appropriate step.
When you build and run your app, a "main dialog window" will be displayed. If you click Esc (or the little x a the top right corner), the dialog will exit, control will eventually return to your CWinApp derived class, and your app will exit.
The actual displaying of graphics will likely occur within a custom control (chart, graph, whatever) you may choose to implement. This control will reside within the dialog. You can create a timer to update the control every "n" units of time. You may also want to add buttons and other widgets on the dialog to allow the user to control the app.
Hope this sheds some more light on "the big picture".
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Ravi,
Thanks for the further tip. I used AppWizard to create
a dialog application. So, now, I have the same question:
Where does my application code go? You mention that
the displaying of graphics will occur within a "custom
control". I don't know that this is -- I think what I'm
looking for is a function (method) that gets called to
run my code.
My goal (for now) is to draw a circle in the dialog window.
I want to do this is my main code section, *not* in the
initialization InitInstance() method. Can you let me
know where I would put this circle code?
I presume that my application code goes in a well-defined
and well-known location in the dialog window code, I'm just
trying to find out what this location is. Can you let me know?
Thanks again, sorry for not "getting it" quicker.
|
|
|
|
|
For a GUI application you need to think in terms of what you do to react to user input, not the classical main approach. As such, do not think of your dialog application as having a main code section - your application responds to messages from the Windows message system, and it is within the handlers for these messages that your application code is distributed as appropriate. In the case of drawing a circle in the window, then you would put that code within the handler for the WM_PAINT message, for example, which is called whenever the window needs to be redrawn. If you bring up the ClassWizard then it allows you to define a whole host of these functions to respond to most things. To stress, dont think of it in terms of having a main code section - Windows handles all that, you just respond to its messages.
|
|
|
|
|
Johnny is exactly right.
Windows (like any event driven GUI) requires your application to respond to events. Windows notifies your application when an event occurs by sending messages to its windows. Each message is identified by a WM_something constant. Examples of messages are:
-
WM_SIZE the user has just resized the dialog
-
WM_MOVE the user has moved the dialog
-
WM_QUERYENDSESSION Windows is shutting down and would like to terminate your application
-
WM_PAINT the user has moved a window, causing (part of) your window to need to be redrawn
MFC conveniently provides predefined methods (that you can override) to customize your response to these messages. The one you probably want to handle is the last one. The handler for this message is OnPaint().
My gut tells me you might be better off doing some reading before venturing into building your app. Once you get a better handle (pun intended) on MFC, you can decide where to inject your application's drawing code and perhaps add more bells and whistles to your app.
Good luck!
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Right now, I am doing quite bad in C++ programming class, and I really have no clue how to start this program. All I need is a kick in the rear (psuedocode), I obviously don't need anyone to type out the code for me.
http://www.cse.psu.edu/~cg103/NewHW/Pj2.pdf
A quick note: The due date is incorrect on there. It is due Tuesday November 18th.
Thanks for your help. I really, really appreciate it ^_^
|
|
|
|
|
You're just talking about setting up 2D arrays and passing over them, aren't you ? To flip, you swap values across one row or column at a time, and to add brightness, you need just add a value to each element, up to a maximum of the max grey specified in the header.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
