|
How do you prevent someone from entering an invalid entry? For instance, the user can enter a "y" or "Y". If they entered anything else, they would receive a message saying invalid entry and be given the chance to re enter their input. I am using Microsoft Visual C++.
|
|
|
|
|
One way could be...
BOOL bOK = FALSE;
CyourDialog newDlg;
do
{
if (IDCANCEL == newDlg.DoModal ())
break;
if ((newDlg.yourParameter == "y") || (newDlg.yourParameter == "Y"))
{ bOK = TRUE;
break;
else
AfxMessageBox ("The entry is not valid, please give a correct value");
}while (bOK == FALSE)
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Hi,
I have written a class that contains an array of pointers to another class object I wrote. In an effort to not waste CPU time by accessing the constructors to the member class until they are needed, I use the allocator class to reserve memory for these member objects. Unfortunately I can only allocate enough memory for about 2 million objects taking up about 450MB in memory. When I try to allocate more (hard coded) the code compiles but crashes when you run it.
I checked the max_size (ie allocator<lploanidtrie> alloc.max_size()) and it returns a value of 15 million. Why does the program not work? This program is coded in VS C++ 2005 and is compiled as a DLL that is called in an Excel application.
Mike
modified on Saturday, December 15, 2007 6:41:20 PM
|
|
|
|
|
You can only allocate a contiguous range of virtual addresses in a single memory allocation call. In a 32-bit application, you have 2GB of virtual address space available [*] but it's fragmented due to the locations that DLLs load at. System-supplied DLLs load towards the end of the available address space but third-party ones tend to have lower addresses. Clearly for your application on your system, the largest contiguous block of address space available is around 450MB.
You'll have to look into managing multiple arrays if your data set is this large.
[*] OK, on a 32-bit machine booted with the /3GB switch, running a version of the OS that supports it, and running a program marked /LARGEADDRESSAWARE you get closer to 3GB available, and the same program running on an x64 machine gets virtually 4GB of virtual address space. It's still fragmented.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Hi.
I'd like to have a cout manipulator which would print to the console description of an instance of a class. E.g.
class MyClass
{
public:
int a;
ostream &Print(ostream &str)
{
str << "a = " << a << "\n";
return str;
}
};
void main()
{
MyClass obj;
obj.a = 1;
cout << "obj: " << obj.Print();
}
Of course the code above doesn't work, but I hope it shows what I meant.
Any ideas?
Thanks in advance.
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
You need to provide an implementation of operator<< for your class and ostream. This is accomplished with a non-member function:
ostream& operator<<( ostream& str, const MyClass& mc )
{
return mc.Print( str );
}You would need to add const to the end of the declaration of Print for this to work, i.e.
ostream& Print( ostream& str ) const otherwise you'll get an error complaining that there's no overload which takes a const MyClass or similar.
You can overload operators as member functions, but they have to be members of the class which appears on the left-hand side of the expression which in this case would mean having to add it to ostream. Clearly that's not practical, so we use a non-member function, where the first argument is the left-hand side of the operator and the second the right-hand side.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thanks Mike.
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
Develop a Win32 application that contains a drop down menu. Add a string table resource to your application that has one string resource named ID_STR. When key combination “ALT+c” is pressed, the window must draw a circle and when “ALT+r” is pressed, the window must draw a rectangle. Similarly when “ALT+t” is pressed then window must draw a string “Virtual University”. The text “Virtual University” must be stored in a string table resource. Application should contain a drop down menu named “Draw Figure”. The sub menus of “Draw Figure” drop down menu should be “Rectangle”, “Circle”, “Text” and “Exit”. All sub menus must be separated by a “separator”. Whenever a user click on one of the sub menus then corresponding figure must be drawn. When user clicks on the “Exit” menu application must terminate. The application must erase the background of the application before drawing new figure or text.
What to Submit
Make a project and add the project workspace in a single folder for this assignment.17 ZIP that folder and send it as your assignment.
Moon
|
|
|
|
|
Funnily enough we don't tend to do people's homework for them.
Develop it yourself. That's the whole point - to see if you understand the principles and if you can actually program. A good teaching environment will take whatever you've produced - whether it works or not - and follow up with you on issues that you're struggling with.
If you're having a specific problem in a small area we can help. But your course should have already shown you how to do this.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Don't waste ur time to give a fake reply.
Thx for understanding.
Have a good day.
|
|
|
|
|
Respected All contributors,
I am developing a program to be run in all windows platform. Its running in tablet and desktop pc. The code was portable to WM5.0 and its running in the release mode. When i build it in DEBUG mode the file size is very big (28MB). The emulator says "System running crtially low in resources", which can be understood. The debug version of the file in Windows Desktop is about 15MB. It has many graphics files embeeded and i have reduced the size of those files including a 246BYTE graphics file for all resources.
I opened the DEBUG file in BINARY format in VS to see wether it has any reference to any BIG BINARY FILES. I have seen that it has allmost 9MB of text which directly or indirectly pointing to "AFXTEMPL.H"
For Example::
H:\Program Files\Microsoft Visual Studio 8\VC\ce\atlmfc\include\afxtempl.h
Or
f:\sp\vctools\vc7libsce\ship\atlmfc\include\afxtempl.h
While the directory does not exist in my system. The text is approximately 9MB. I dont know what has caused the compiler to include so much text to the DEBUG binary and its causing the DEBUG file to be big in size and unable to load in EMULATOR.
I did check with mcafee virus scan for any virus, it said no viruses detected. I created an MFC smart Device Application in SDI format and run it without adding any code to the default AppWizard generated files. It also shows similar problem and included a BIG size of text similar to the above shown text in the DEBUG build. All the MFC related projects shows the same problem, wether its dll , activex or standalone.
This is a cad project and does not have any linking to ODBC or DB or any other similar items. It uses the GDI and no external libraries, but since the AppWizard generated files itself showing the problem. There might be something else wrong!!!
Recreate the problem:
Start MS VC 2005 Sp1. File -> New -> Project -> Smart Device -> MFC Smart Device Application
Platforms -> Windows Mobile 6.0 Profesional SDK
Finish. & Run
Open the file in the VS Editor (MS VC 6.0 eVC4.0 or 3.0) in binary mode. Search for text "afxtempl.h" in the created executable file in debug mode. Thanks in advance for your effort. The file that was created on my machine for the form view SDI is (1,631,232 bytes). Is that normal?
I request all the contrinutors to give some light into this if you had faced similar problems or heard of it!!!
I have added a youtube video showing the problem::
http://www.youtube.com/watch?v=nA2d3gCtglk
All Comments and thoughts welcome...
Thank you very much for your time,
Have a nice Day.
Sincerely
Suresh Kumar
|
|
|
|
|
Whenever you build a debug build, the compiler records the source file and line number of every statement that's compiled in in the debug information. When you use a C++ template, you get a separate copy of the code for each different set of parameters for the template. Sometimes the compiler can consolidate them but it may not do this for debug builds.
I would normally expect the debug information to be recorded in the Program Database (.pdb) file. However, some options cause it to be recorded in the actual executable and I suspect you've set one of those.
Also note that the default in Visual Studio 2005 is to use MFC in a static library. This means that the prebuild .lib files are statically linked into your executable. The debug options to the linker turn off the /opt:ref option, which causes unused code to be discarded, which means that the entirety of the runtime is linked into your program. This could be another source of lots of the overhead.
I don't currently have the tools installed but will confirm once I have (just upgrading to Windows Vista now).
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thank you very much for your time.
I have set the /opt ref option, but it does not solve the problem. If you could get the time, please do create a smart device MFC enabled project (preferably MFC->SDI->Form View) and check the generated debug binary to see the amount of text dumped into it. my desktop debug does not dump this much amount and has added only a single reference to "Afxtempl.h", which is ideal and consumes only below MAX_PATH byte in the debug binary.
If i am unclear on any thing, please do let me know.
Thanking you.
Suresh
|
|
|
|
|
I can confirm that the newly-generated project for a Windows Mobile 6 Professional MFC SDI app is indeed around 1.6MB.
I've also worked out what the source of the information is. It's down to use of ASSERT.
The definition of ASSERT is as follows (afx.h, line 416):
#define ASSERT(f)\
DEBUG_ONLY((void) ((f) ||\
!::AfxAssertFailedLine(THIS_FILE, __LINE__) ||\
(AfxDebugBreak(), 0)))(reformatted for clarity).
The THIS_FILE macro is defined as __FILE__. This is a built-in macro that expands to the filename of the current file being processed. Recording the file and line number in this way allows a meaningful message box to be displayed if the assertion fails. Most MFC headers don't contain any significant implementation, so don't perform any ASSERTs, but afxtempl.h has its implementation in the class body (it has to, they're templates) and does.
The reason that there are two paths is that the ones coming from uses of afxtempl.h in the static MFC library were included in that library when it was built - this is the path that doesn't exist on your computer. The other is the one coming from uses of the header in your code. You may think you don't use it, but in fact for some reason the MFC classes CPtrArray and CMapPtrToPtr have been defined in terms of CArray<> and CMap<>, respectively. These classes are used by CArchive which is at the root of the document-saving facility. I have no idea why this is the case - maybe someone thought they were saving space by omitting these non-template classes! Worse, they're still included in afxcoll.h, and in the MFC libraries, anyway!
I think all you can try is to use the 'string pooling' option (/GF) in the compiler options (Configuration Properties, C/C++, Code Generation, Enable String Pooling). This causes identical constant string literals to only be included in each compiled source file once, but note that they're stored in read-only memory so you might need to check that you don't try to write back to string literals.
I forgot to mention that /opt:ref removes unreferenced COMDATs. A COMDAT is basically just a marked independent chunk of code. For a debug build, the compiler effectively emits a single COMDAT per source file except where C++ semantics require that there's only a single definition of something (for example, the out-of-line version of an inline function). If you specify the /Gy option (Code Generation, Enable Function-Level Linking), the compiler emits each function as its own COMDAT. This can be annoying for debugging, however, as you can only call referenced code from the debugger expression evaluator. If there's a function that wasn't referenced in your program, the linker will eliminate it. The /DEBUG option to the linker suppresses the default /OPT:REF - if you want both you have to explicitly enable /OPT:REF.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
I got accustomed to programming in Borland C++ 4.5, which does not use classes. Please where can I download some Visual C++ programs (it does not matter what they do), so I can see how to program for Windows using classes (e.g. the class called "Window")?
|
|
|
|
|
Its easy to use of classes (your classes or MFC classes)
class CMyclass: public CImage
{
public:
CMyclass(CWnd* pParent = NULL);
};
.....
....
void CMain::functions()
{
CMyclass localclass;
CDC m_Images; //MFC class
}
|
|
|
|
|
Anthony Appleyard wrote: I got accustomed to programming in Borland C++ 4.5, which does not use classes.
Did you use a C++ compiler to compile only plain C code? 
Anthony Appleyard wrote: Please where can I download some Visual C++ programs (it does not matter what they do), so I can see how to program for Windows using classes (e.g. the class called "Window")?
If you have the Visual Studio 2008 Express Edition (as you stated it in a previous post) then you cannot use the MFC classes (e.g. CWnd).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
My Borland C++ 4.5 compiler could understand classes etc, but it dod not use classes to represent any Windows processes.
|
|
|
|
|
Anthony Appleyard wrote: but it dod not use classes to represent any Windows processes.
It did if you used OWL, just like VC++ does when you use MFC.
Mark
|
|
|
|
|
Anthony Appleyard wrote: so I can see how to program for Windows using classes (e.g. the class called "Window")?
Where did you see a class called "Window"?
As mentioned by Hamid, Visual C++ (non-Express versions) comes with the MFC
library which is a class-based framework wrapping the Win32 APIs.
If MFC is what you are interested in, you can build a fully functional
MFC application with the project wizards. See File/New/Project... in
Visual Studio.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
I have got my program project working. With thanks to all who have answered my queries. (I have the free download version of Visual C++ 2008.) (It is like Windows Character Map, but its display is much bigger and clearer, and it can handle all 65536 Unicode characters.) This query arises: Can the resulting ---.exe file run on another computer? Or what needs to be doing to it or to be uploaded along with it?
|
|
|
|
|
Im sorry understand what you said?
|
|
|
|
|
|
Hi All,
I have very serious problem regarding using DllMain() function in my application.I have created MFC Activex Control in VS2005.
I have created one .cpp file in that I want to use DllMain() function as below....
BOOL WINAPI DllMain (HANDLE hInst, ULONG ul_reason_for_call, LPVOID lpReserved)<br />
{<br />
}
But when I use this function (At least these three lines..  ) I got an error like below....
Hooking.obj : error LNK2005: _DllMain@12 already defined in mfcs80ud.lib(dllmodul.obj)<br />
ActivexVS05.ocx : fatal error LNK1169: one or more multiply defined symbols found
I have searched for this error in google but I could not found the solution.
If you have any suggetion and solution then please reply me.
Thanks in Advance.
|
|
|
|
|
MFC implements DllMain for you. Override the InitInstance method instead.
Read the DllMain[^] article very carefully, and the Best Practices for Creating DLLs[^] white paper. Note particularly that calling MFC methods may not be safe if MFC has not yet initialised, if you're using MFC in a shared DLL.
In general I would recommend avoiding any initialisation steps in DllMain and instead perform them in the class itself (perhaps in the constructor).
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
