C / C++ / MFC

Re: Edit Box Notification

29-Jul-05 14:29

The simpilst approach may be to just subclass the control and look at the WM_CHAR messages on there way thru.

See "ID: Q174667" in the MSDN library.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Stan the man29-Jul-05 17:13

Stan the man

29-Jul-05 17:13

Hi.

I had a similar situation. What I do is this:

In OnChar, I set a var to detect if something is being entered. If so, then in the DefWinProc if the message is WM_SETTEXT, then I do NOT accept it so that the Text you are entering on screen is NOT being overriden but is SAVED to variable. In the Pretranslate Message, if the message is WM_KEYDOWN with VK_RETURN, it will then accept this new entry you just entered on screen. If there is no enter and the focus is lost then it will set the text to that Last SAVED text (from other parts of the program OR last entered data.

I hope this will help a little.

Very very stupid question

Lampros Giampouras29-Jul-05 12:53

Lampros Giampouras

29-Jul-05 12:53

This question is probably stupid and cannot be done, but you never know..

I use microsoft visual c++ studio, and the white background is hurting my eyes for all the time I look at it. The question is if there's a way to make the background black and the code white or something.. Is there?

John R. Shaw29-Jul-05 13:48

29-Jul-05 13:48

On VC++ 6.0: Tools->Options->Format[tab].

White backgounds have always hurt my eyes, to I use a gray background. Using a black background is almost as bad.

I also set my the display properties for the system to use gray window backgounds, that way most programs, like notepad, popup with a gray background.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Toby Opferman29-Jul-05 14:00

Toby Opferman

29-Jul-05 14:00

I suggest trying bright orange background with yellow text.

8bc7c0ec02c0e404c0cc0680f7018827ebee

John R. Shaw29-Jul-05 14:20

29-Jul-05 14:20

My eyes, my eyes, ahhhh!

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

ThaSaVa30-Jul-05 0:01

ThaSaVa

30-Jul-05 0:01

Yes you can use

Tools->options->Format->SourceWindow then apply the foreground and background colors
as you want

cheers Big Grin | :-D

comport; never reaches EOF?

Lampros Giampouras30-Jul-05 2:48

Lampros Giampouras

30-Jul-05 2:48

These helped a lot..! Thanks guys!

localizing problem

Razi Al-Sayed29-Jul-05 9:53

Razi Al-Sayed

29-Jul-05 9:53

hi all,
i want to ask if any one has an experience with localizing under vs6, i am working on an application with arabic interface, and i know that is the only way to change the resources files to arabic is by editing the .rc file and change the language from:
LANGAUGE LANG_ENGLISH, SUBLANG_ENGLISH_US
to
LANGUAGE LANG_ARABIC, SUBLANG_ARABIC_SAUDI_ARABIA

when i done this every thing goes fine, and i can compile the project with out any problem, but when i close the workspace and want to open it again it does not opened.

i tried to delete the workspace file and open the project one, but it does not opened to, and "out of memory" message box appears.

Please help me.

Razi. Confused | :confused:

Re: localizing problem

Michael Dunn29-Jul-05 19:09

Michael Dunn

29-Jul-05 19:09

You can change languages through the IDE. Right-click->Properties on any resource in the tree and the properties window will have a combobox where you can pick the language.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | 1ClickPicGrabber | NEW~! CP SearchBar v3.0 | C++ Forum FAQ
Pinky, are you pondering what I'm pondering?
I think so Brain, but if we shaved our heads, we'd look like weasels!

quarry_0629-Jul-05 9:15

quarry_06

29-Jul-05 9:15

Problem Solved. I was looking for the wrong EOF sign.

I have a while loop

bool fContinue = true;<br />
	do<br />
	{<br />
		// Wait for an event<br />
		lLastError = serial.WaitEvent();<br />

Inside this loop, I receive data and process it.

<br />
if (eEvent & CSerial::EEventRecv)<br />
		{<br />
			// Read data, until there is nothing left<br />
			DWORD dwBytesRead = 0;<br />
			char szBuffer[101];<br />
			do<br />
			{<br />
				// Read data from the COM-port<br />
				lLastError = serial.Read(szBuffer,sizeof(szBuffer)-1,&dwBytesRead);<br />
				if (lLastError != ERROR_SUCCESS)<br />
					return ::ShowError(serial.GetLastError(), _T("Unable to read from COM-port."));<br />
<br />
				if (dwBytesRead > 0)<br />
				{<br />
					// Finalize the data, so it is a valid string<br />
					szBuffer[dwBytesRead] = '\0';<br />
<br />
					// Display the data<br />
					printf("%s", szBuffer);<br />
					write2file(szBuffer);<br />
					<br />
					// Check if EOF (CTRL+'[') has been specified<br />
					if (strchr(szBuffer,EOF_Char))<br />
						fContinue = false;<br />
				}<br />
			}<br />
		    while (dwBytesRead == sizeof(szBuffer)-1);<br />
                   }<br />
	}<br />
while (fContinue);<br />

now what happens, that it somehow never sets fContinue to false.
but the first function I call, serial.WaitEvent();, doesn't get something either, and I can see that in fact all the expected data has arrived. Is it that code running on the other side of the comport does not send the proper EOF? or what could it be?

thanks for any suggestions

MFC Dll in non-MFC app?

Anacreon29-Jul-05 7:55

29-Jul-05 7:55

Hi all, I have a DLL written in MFC (and tested extensively with MFC client apps) that I am not trying to link to from a non-MFC app. The code crashes inside the CInternetSession constructor on a call to call to AfxGetAppName. Is this a sign that I can't use the DLL in a non-MFC app, or is there something more subtle to it? Is there any workaround?
Thanks

One other note

Anacreon29-Jul-05 8:25

29-Jul-05 8:25

Actually 2 points I should mention -- this DLL works fine with the non-MFC app except for the portion of it that uses WinInet functionality. And also, I am linking indirectly to the DLL through an ActiveX object which is written with ATL. The application which is loading the ActiveX object, is written in Visual Basic.

Michael Dunn29-Jul-05 9:46

Michael Dunn

29-Jul-05 9:46

Look up AFX_MANAGE_STATE in MSDN, you need to use that at every entry point into the DLL that might be called from a non-MFC app.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | 1ClickPicGrabber | NEW~! CP SearchBar v3.0 | C++ Forum FAQ
Ford, what's this fish doing in my ear?

Anacreon29-Jul-05 10:07

29-Jul-05 10:07

Thanks -- I'll take a look.

Anacreon29-Jul-05 10:27

29-Jul-05 10:27

Well when I put calls to AFX_MANAGE_STATE in, the compiler complains that I have multiple defines of __pRawDllMain and _DllMain@12 -- it is tring to link in dllmodul.obj in mfcs42d.dll and these symbols are defined in my own object code.

By the way, the crash is happening on a worker thread so there is no non-MFC code on the call stack. Don't know if that makes a difference.

Anacreon29-Jul-05 10:44

29-Jul-05 10:44

OK -- I see now that my problem may be, that I don't have a CWinApp-derived class in my DLL -- just a DllMain. I am going to switch over to a CWinApp object and insert the AFX_MANAGE_STATE calls, hopefully that will clear it up.

#include problem

massad29-Jul-05 6:03

massad

29-Jul-05 6:03

This seems like a straightforward problem but I am totally stumped and just can't figure it out. It seems that whenever some changes are made in some of the classes in my project (Specifically a newly added function takes a parameter of a different type class from the Project), the "location" of the include line for that class must be changed inside the "stdafx.h". Otherwise the compiler complains that it does not know what the Object being passed in is.

Here's an example:

[stdafx.h]

#include "class1.h" //the order of files here seems to cause problems.
#include "class2.h"

[class1.h]

#include "stdafx.h"
..... //some code

void Test(Class2* pClass); << //C2061 error occurs on this line saying it does not know what Class2 is!!!!

However if I switched around class2.h to be followed by class1.h in the stdafx.h there would be no problem.

Maybe I am doing something wrong but if I put all the include files into the stdafx.h and them simply include it in every class header file, shouldnt the compiler be able to know what all the classes area?

Any help is greatly appreciated.

Sincerely,

Ilya

John R. Shaw29-Jul-05 6:36

29-Jul-05 6:36

massad wrote:
shouldnt the compiler be able to know what all the classes area?

No. The order of the header files can be important. If a prototype in class1.h needs to know about a type defined in class2.h then class2.h normaly needs to be included before class1.h.

Most developers, now days, put a guard define# in there headers so that they will not be included twice (prevents include recursion). This also give you the advantage of allowing you to include any header files (w/guards) in any header file that needs the types defined in that header. It is also why C++ allows you to declare a class type, before it is define.

// class1.h
#ifndef _CLASS1_H_ // guard
#define _CLASS1_H_
#include "class2.h"
class class1 {...}
#endif // _CLASS1_H_

// class1.h
#ifndef _CLASS1_H_ // guard
#define _CLASS1_H_
class class2; // forward declaration
class class1 {...}
#endif // _CLASS1_H_

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

massad29-Jul-05 6:50

massad

29-Jul-05 6:50

Thank you John,

I have fixed the problem. Before I posted here, I tried to use forward declaration and the guards but I still seemed to have the errors appear.

The problem seems to have stemmed from the fact that the code was all inline in the header file (this is the way it was given to me, I didnt write it) and no code was put into the .cpp file.

While trying to figure out what the problem was, I had become fed up with all the code being inline and split it up between a header and the source and the problems disappeared.

Out of curiousity, so that I know for future reference, is there a problem with forward declarations if all the code is inside a header file?

John R. Shaw29-Jul-05 7:07

29-Jul-05 7:07

massad wrote:
is there a problem with forward declarations if all the code is inside a header file?

I would not think so. At least I have had no problems, resonantly.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Bob Stanneveld29-Jul-05 7:41

Bob Stanneveld

29-Jul-05 7:41

Hello,

It seams that a problem with including to many headers. You should not include stdafx.h in your header.

The problem that you face is that you include stdafx.h in class1.h. In stdafx.h, you include class1.h, which in turn includes stdafx.h again. This is an infinite cycle and the compiler knows this. It just stops including and you get some errors.

If you don't use class1 in class2, you can include class2.h instead of stdafx.h in class1.h and you problem should be gone!

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

Anacreon29-Jul-05 7:58

29-Jul-05 7:58

#include "stdafx.h" is a signal to the compiler to use the precompiled header -- your compiler will perform better if you don't include stdafx.h in header files, instead include it as the first include file in your source files.