C / C++ / MFC

harold aptroot14-Aug-09 3:00

14-Aug-09 3:00

The Windows multimedia timers[^] might be useful

Rajesh R Subramanian14-Aug-09 5:24

14-Aug-09 5:24

Actually, they won't help. The OP wants resolution in terms of microseconds!

It is a crappy thing, but it's life -^ Carlo Pallini

harold aptroot14-Aug-09 5:33

14-Aug-09 5:33

Well it's going to be better than a standard timer, so it's at least closer

Rajesh R Subramanian14-Aug-09 5:45

14-Aug-09 5:45

I was particularly avoiding in providing any possible solution to him, because the OP's approach has a fundamental flaw (introducing 'artificial' delays in his code). And to answer you, NO, multimedia timers are neither going to provide resolutions any closer to microseconds! Not under Windows.

It is a crappy thing, but it's life -^ Carlo Pallini

harold aptroot14-Aug-09 5:47

14-Aug-09 5:47

Rajesh R Subramanian wrote:
And to answer you, NO

I do not claim that they have a resolution of microseconds. But they have a resolution which is considerably higher than the standard timer so they come closer to the goal. Sure they don't reach it, but being closer is better than .. well.. not being closer

Rajesh R Subramanian14-Aug-09 8:46

14-Aug-09 8:46

harold aptroot wrote:
But they have a resolution which is considerably higher than the standard timer so they come closer to the goal. Sure they don't reach it, but being closer is better than .. well.. not being closer

Well, why don't you understand? Do I have to say again? It is NOT closer to the goal. The goal itself, is unachievable. Windows does not support such things. Not to mention the OP's approach is flawed.

For an OS to provide real-time functionality, it would require a very strong knowledge of the underlying hardware (including how fast each and every device is, how fast is the bus, the processor, how will they behave under specific conditions, etc.,). However, Windows was designed to support a wide variety of hardware, which means that the OS cannot practically have a deep knowledge of each and every hardware device that it may have to work with. So they had to compromise on this part.

Is that you down-voting? Why? Because I don't agree with your comment? Well, your comment is WRONG.

It is a crappy thing, but it's life -^ Carlo Pallini

harold aptroot14-Aug-09 9:00

14-Aug-09 9:00

You think it is not closer. But it is. He's never going to reach the goal, but a better resolution takes him closer to his goal. Just because you can not get there doesn't mean you can not get closer.

And yes I gave you a 3, not because you disagree but because You are the one who is partically wrong. It would be closer to his goal.
It's like trying to reach 0K (zero Kelvin) really - you won't reach it, but you can get a lot closer than your kitchen freezer (which would be the normal timer in this analogy)

So why won't I understand? Because it isn't true in the first place.

edit: and here's an other one: suppose someone says "I want to get positive infinity using an integer! I am using uint32 now but it won't go high enough", well of course he can't reach it, but he could get closer using an uint64. It could be that he didn't really need infinity but just "something really high" and that it would help him anyway, just as in this case the OP may not know that multimedia timers exist and they may be good enough for what he's doing - who knows? At least he will be better off knowing that they exist.

Rajesh R Subramanian14-Aug-09 9:40

14-Aug-09 9:40

harold aptroot wrote:
At least he will be better off knowing that they exist.

Fine, he'll know that such a thing exists. That's the only point I can take. But, I won't take the "it's closer to the goal" codswallop.

harold aptroot wrote:
And yes I gave you a 3, not because you disagree but because You are the one who is partically wrong. It would be closer to his goal.

Now, you're being ridiculous. How is it closer? He's trying to achieve something that would require an RTOS, but is doing that task on Windows. So, how is any approach going to be closer to the goal? Not only you don't know about the subject, but you're also down-voting because you think that I'm wrong.

How long have you been doing C++ or programming Windows to say that using a multimedia timer can be closer to make Windows behave like an RTOS? I'd assume that you're a teenager, have never worked on any professional project, and are talking about stuff that you know superficially (or know nothing about) here. I'm not wasting another minute on you.

It is a crappy thing, but it's life -^ Carlo Pallini

harold aptroot14-Aug-09 10:03

14-Aug-09 10:03

Rajesh R Subramanian wrote:
I'm not wasting another minute on you.

Well thanks. But in my world any improvement means you're closer. And going from normal timers to multimedia timers is definitely an improvement if your goal is a very short wait. Thus it is closer. Are you getting extremely offensive over a definition of "closer"? Come on now.

Rajesh R Subramanian wrote:
He's trying to achieve something that would require an RTOS

Yes, so it's impossible, but so what? You can still get a lot closer to the goal than a 18ms resolution.

Honestly now, an answer that is not right does not deserve a 5, a 4 is more fitting, you do have a point, however your definition of closer does not match the one in the dictionary.
This isn't even a programming matter, it's just you having odd definition of being closer to a goal.

Btw including my age in the argument is argumentum ad hominem - in other words, you would be wrong by default.

SMTP: all are not working?

hanlei000000000915-Aug-09 3:41

hanlei0000000009

15-Aug-09 3:41

Thanks all.

It's looked like I need transplant my project From Windows to Linux or Unix.

timeval's member tv_usec is a value in microseconds. It declaration and used in UNIX first.

So, I think UNIX, FreeBSD for example can do this as possible.

Grab Key board focus

aks.13-Aug-09 18:51

aks.

13-Aug-09 18:51

hi,

I have 2 applications A & B. They are started independently.
Application B can show/hide Application A.( Using named events and threads)
Scenario 1:
A is displayed.
A is hide( SW_HIDE ) by itself by clicking a button on A.
A is showed from B.
::SetWindowPos( this->m_hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE );
::SetWindowPos( this->m_hWnd, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE );
SetActiveWindow();
SetFocus();
GetDlgItem( IDC_EDIT1)->SetFocus();
In this case A is displayed and has the Key board focus.

Scenario 2:
A is displayed.
A is hide from B.
A is showed from B.
In this case A is displayed and has the cursor is blinking on the edit control of A. But it doesn't have the Key board focus. i.e. if I press the tab to change the focus, application B's tab order is changing.

Could you please let me know how can I get the key board focus on above case( Scenario2). I know that AttchThreadInput can solve this issue. But I need to know whether any alternate solution for this.

aks

Re: Grab Key board focus

«_Superman_»13-Aug-09 18:58

«_Superman_»

13-Aug-09 18:58

Try SetForegroundWindow[^] or BringWindowToTop[^]

«_Superman_»
I love work. It gives me something to do between weekends.

includeh1013-Aug-09 15:03

includeh10

13-Aug-09 15:03

I developed a SMTP tool several years ago (using win 98) and it worked well.

Now I need to send email in my app, so I test the SMTP tool again - it is not working now.

I downloaded several samples from CP articles, all of them are not working.

I am wondering why?
Is my OS (win2k) problem or anti-virus software blocked mail or something else?

Any suggestion?

zhu_lin13-Aug-09 15:46

zhu_lin

13-Aug-09 15:46

check whether your SMTP server is open.

and what's your smtp function return value?

it's my pleasure to make friend with you.

Bacon Ultimate Cheeseburger13-Aug-09 15:48

13-Aug-09 15:48

includeh10 wrote:
anti-virus software blocked mail

Anti-virus and firewall software is one of the most common causes of the problem you are experiencing. It's also possible that your ISP is blocking port 25 (some do, some don't) in an effort to reduce spam on their network. Without more information such as what operation it's failing on (connect, send, etc.) it's hard to tell.

Have you tried disabling your anti-virus and/or firewall and then running your app?

I am a lean mean ground beef machine!!!

includeh1013-Aug-09 16:08

includeh10

13-Aug-09 16:08

Here is info:

1. none of commands return SOCKET_ERROR.
2. for QUIT command, ::recv() returns zero - this should be OK
3. ::gethostbyname("www.mycompany.com") - I use my company's domain, is this problem?

Thanks.

Bacon Ultimate Cheeseburger13-Aug-09 16:22

Re: SMTP: all are not working? [modified]

13-Aug-09 16:22

If your SMTP client does not handle authentication the first thing I would check is to make sure that the server you are connecting to does not require it. Also make sure that the server allows relaying from the location you are connecting from (it probably does if it's an internal company server but it's always best to make sure).

If that doesn't provide any answers I would load up a packet sniffer and monitor the transmissions between your application and the SMTP server. This should give you a better idea of how well the server is responding to your client. It's possible the server is returning an error that your client is not handling (hard to say without seeing the code).

If neither of those provide you with any answers you might want to try installing a bare bones SMTP server on a test machine and seeing if your client (and the other examples you have downloaded) works with it.

I am a lean mean ground beef machine!!!

includeh1013-Aug-09 16:19

includeh10

13-Aug-09 16:19

Here are all test code, are there errors?

#define CHECK(iStatus) \
if(iStatus==SOCKET_ERROR) return 0;\
if(iStatus==0) return 0

#define EOL  "\r\n"

BOOL TestSend()
{
	const char*pszServer="www.mycompany";
	const char*pszSmtpEmail	="myemail@hotmail.com";
	const char*pszSenderEmail	="myemail@hotmail.com";
	const char*pszSubject	="my subject";
	const char*pszReceiver	="myemail@hotmail.com";
	const char*pszBody		="the body";
	const char*pszSenderName	="myemail@hotmail.com";

	char	sz[1024];
	char	wa[1024];
	char	szBuffer[4096];
	char	waTime[270];

	int iRet;
	//-------------------------
	HOSTENT* pHost=::gethostbyname(pszServer);
	if(pHost==0) 	return 0;
	SOCKET hSock=socket(PF_INET,SOCK_STREAM,0); 
	if(hSock==INVALID_SOCKET) return 0;

	SERVENT*pServer=::getservbyname("mail",0);

	const int iPort=pServer?pServer->s_port:IPPORT_SMTP;

	SOCKADDR_IN    sockAddr;
	sockAddr.sin_family	=AF_INET;
	sockAddr.sin_port	=iPort;
	sockAddr.sin_addr	=*((LPIN_ADDR)*pHost->h_addr_list);

	if(::connect(hSock,(PSOCKADDR) &sockAddr,sizeof(sockAddr)))
	{
		return 0;
	}
	iRet=::recv(hSock,szBuffer,sizeof(szBuffer),0);
	// Receive initial response from SMTP server.
	CHECK(iRet);

	// Send HELO 
	wsprintf(sz,"HELO %s%s","microsoft [111.122.1.12]",EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));
	CHECK(::recv(hSock,szBuffer,sizeof(szBuffer),0));

	// Send MAIL FROM:
	wsprintf(sz,"MAIL FROM: <%s>%s",pszSmtpEmail,EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));
	CHECK(::recv(hSock,szBuffer,sizeof(szBuffer),0));

	// Send RCPT TO: 
	wsprintf(sz,"RCPT To: <%s>%s",pszReceiver,EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));
	CHECK(::recv(hSock,szBuffer,sizeof(szBuffer),0));

	// Send DATA.
	wsprintf(sz,"DATA%s",EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));
	CHECK(::recv(hSock,szBuffer,sizeof(szBuffer),0));

	///szHead
	strcpy(waTime,T("Date: "));
	::GetDateFormat(0x409,0,0,T("ddd,dd MMM yyyy"),wa,200);
	strcat(waTime,wa);
	strcat(waTime,T(" "));
	::GetTimeFormat(0x409,0,0,T("HH:mm:ss"),wa,200);
	strcat(waTime,wa);

	char szHead[350];

	strcpy(szHead,"From: ");
	strcat(szHead,pszSenderName );
	strcat(szHead,"<");
	strcat(szHead,pszSenderEmail);
	strcat(szHead,">");
	strcat(szHead,"\r\n");
	strcat(szHead,"To: ");
	strcat(szHead,pszReceiver);
	strcat(szHead,"\r\n");
	strcat(szHead,"Subject: ");
	strcat(szHead,pszSubject );
	strcat(szHead,"\r\n");
	strcat(szHead,waTime);
	strcat(szHead,"\r\n");
	strcat(szHead,"X-Mailer: Outlook Express 1.00\r\nMIME-Version: 1.0\r\nContent-Type: text/plain;\r\n\tcharset=\"iso-8859-1\"\r\nContent-Transfer-Encoding: 7bit\r\n\r\n");

	wsprintf(sz,szHead);
	CHECK(::send(hSock,sz,strlen(sz),0));

	char szBody[4800];
	strcpy(szBody,pszBody );

	strcat(szBody,"\r\n\r\n");
	CHECK(::send(hSock,szBody,strlen(szBody),0));

	// Send blank line and a period.
	wsprintf(sz,"%s.%s",EOL,EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));
	CHECK(::recv(hSock,szBuffer,sizeof(szBuffer),0));

	// Send QUIT.
	wsprintf(sz,"QUIT%s",EOL);
	CHECK(::send(hSock,sz,strlen(sz),0));

	//****** iRet==0, this may be error? 
	iRet=::recv(hSock,szBuffer,sizeof(szBuffer),0);

	// Close server socket and prepare to exit.
	closesocket(hSock );
	WSACleanup();
	return 1;
}

modified on Thursday, August 13, 2009 10:44 PM

Bacon Ultimate Cheeseburger13-Aug-09 16:35

13-Aug-09 16:35

For future reference please wrap your code postings in a <pre></pre> code block so that it's easier to read.

I am a lean mean ground beef machine!!!

Bacon Ultimate Cheeseburger13-Aug-09 18:45

Intercept a WM message into a C++ class

13-Aug-09 18:45

Disregard my last post about recv()...my meds are making me way too fuzzy Smile | :)

Ok, I was able to compile and run it and everything worked fine after a couple of changes. The first problem is with the CHECK() macro:

#define CHECK(iStatus) \
if(iStatus==SOCKET_ERROR) return 0;\
if(iStatus==0) return 0

DO NOT DO THIS! When this macro is expanded by the preprocessor the send or recv operation passed as iStatus will be executed twice:

if(::send(hSock,sz,strlen(sz),0)==SOCKET_ERROR) return 0;
if(::send(hSock,sz,strlen(sz),0)==0) return 0

Instead you might try something like this (until you get everything fixed):

#define CHECK(iStatus) \
{	\
	int result = iStatus;	\
	if(result==SOCKET_ERROR) return 0;	\
	if(result==0) return 0;	\
}

Every email client I tried did not like the date format included in the message header. The following change should work:

::GetDateFormat(0x409,0,0,T("dd MMM yyyy"),wa,200);

I am a lean mean ground beef machine!!!

428813-Aug-09 13:10

4288

13-Aug-09 13:10

I was wondering how to intercept a WM_ specific message into a C++ class, I need to use the RegisterDeviceNotification function to register a specific WM_ message (I need a window here right?) and then intercept it and call the appropriate function

The C++ class should be included in any project, from a console one to a win32 to a mfc one. My idea is to create the skeleton of a win32 window and then use the WndProc for that window, is this stupid?

Is there any (surely) better solution?

---

Baltoro13-Aug-09 14:55

Baltoro

13-Aug-09 14:55

You definitely need to have a Window Proc to recieve your message, because it is associated specifically with a registered Windows class. The documentation over at MSDN should show you how. See this: Windows Procedures Overview[^]
You can also define your own custom Windows messages using a define, and by selecting a value above WM_USER.

KarstenK13-Aug-09 21:13

KarstenK

13-Aug-09 21:13

an own WinProc is the generic solution. But be aware that it dont gets "spaghetti ocde" WTF | :WTF:

Press F1 for help or google it.
Greetings from Germany

428814-Aug-09 4:49

4288

14-Aug-09 4:49

If I put the WinProc function in my class, it will need a hwnd handle I think.

What handle am I supposed to give it? Should I require one to the application which is going to use my class? (this would exclude console apps, that's just a pity)

---