|
Slight warning here: ATL 3.1 (shipped with VC 6.0) uses _alloc to allocate memory. For a large string, you can get stack overflows.
ATL 7.0 uses the heap to allocate memory for the new string.
In the general case, use mbstowcs or MultiByteToWideChar.
|
|
|
|
|
MultiByteToWideChar function will convert Char string WCHAR string and WideChartoMultiByte function does the opposite way.
|
|
|
|
|
|
|
I would like to know about hooking modal windows. Currently I am using SetWindowHookEx which could hook all toplevel windows and I could hook modal dialogs by using WH_CALLWNDPROC and WM_INITDIALOG but I could not hook other modal windows.
Expecting earliest solution.
Thanks and Regards
S.L.Rao
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
