|
hi i want to capture the key pressed by the user and have to do the corresponding functions. can anyone tell me such events
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
See WM_KEYDOWN and WM_KEYUP
|
|
|
|
|
|
thanks a lot. its very useful. but when i press esc key keeping the focus in editbox the dialog closes. instead of this the tab containig the dialog should be closed what i have to do
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
I want to implement a program that would check that a connected device like speaker,webcam,... is properly connected or not.Please reply me as soon as possible.
Thanks & Regards
Pankaj
|
|
|
|
|
Befor I do something like this ..
CString input;<br />
sprintf_s(buf, 16, "%d", input);
I'd like to know whether the input is a number, but how ?
Thanks for a fast answer in advance!
alex
-- modified at 5:18 Thursday 8th March, 2007
|
|
|
|
|
It depend on what type of variable is input ? How its been initialzed ?Can you be little clearer about question ?
|
|
|
|
|
Well, sorry ...
The var input is a CString
I'd like to print an error if someone submits an alpha instead of a numeric input.
alex
|
|
|
|
|
Use CRT function isdigit .
But, again this will work for single character.
|
|
|
|
|
I have a suggestion for you use of Edit controls and set the property of control to number
|
|
|
|
|
BOOL Flag = TRUE;
int length = input.GetLength();
for(int x = 0; X < length; x++)
{
if(!IsDigit(input.GetAt(x)))
{
Flag = FALSE;
break;
}
}
if(Flag)
{
// input is numeric
}
else
{
// input isn't numeric
}
if you need to check if input is a number (integer or float) the following code will work
BOOL Flag = TRUE;
int length = input.GetLength();
for(int x = 0; X < length; x++)
{
if(!IsDigit(input.GetAt(x)))
{
if(input.GetAt(x) == '.'
continue;
Flag = FALSE;
break;
}
}
if(Flag)
{
// input is numeric
}
else
{
// input isn't numeric
}
mohamed sobh
|
|
|
|
|
Hi all,
i want to develop the .msi package which supports multiple language user interface. where i can get the tutorials regarding the same.
Thanking you
Manjunath S
GESL
Bangalore
|
|
|
|
|
Dear Sir
My OS is Win XP i Format My HD, when i format it i lost my vol id, before formation i backup my win registry file in save place, any possable to retrive my previous vol id from win registry file which i backup in save place
Md Firoz Khan Noor
Dhaka, Bangladesh
|
|
|
|
|
Md. firoz Khan Noor wrote: any possable to retrive my previous vol id from win registry file...
Possibly, but why would you need/want to?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello,
I have a class derived from CMDIChildWnd like this
class Wind : public CMDIChildWnd
{
View1 m_View1;
}
class View1 : public CScrollView , public MyView
{
CRichEditCtrl* cedit;
}
Now when I create the objects of the above classes in each of the create I need to give the parent frame. so in this case
CMainFrame* pFrame = STATIC_DOWNCAST(CMainFrame, AfxGetApp()->m_pMainWnd);
Wind WindObj* = new Wind;
Wind->Create(NULL, "FrameName",WS_VISIBLE ,
CRect(0, 0, 0, 0), pFrame, NULL);
View1 View1Obj* = new View1;
CScrollView::Create( NULL,NULL,AFX_WS_DEFAULT_VIEW,
CRect(0, 0, 0, 0), WindObj, NULL);
CRichEditCtrl* cedit = new CRichEditCtrl;
cedit->Create(WS_CHILD|WS_VISIBLE, CRect(10,10,50, 50), View1Obj, 1);
But cedit doesn't work with View1Obj.Instead if I provide the parent to Wind the CRichEdit Box is created.
I thought that the CRichEditCtrl box is made on the View so View pointer can be the parent then how come CMDIChildWnd is the parent of CRichEditBox.
Any clues how a parent is to be decided?
Prithaa
|
|
|
|
|
Hello,
I have a question for you. We have a MFC Single Dialog application that has to be translated in Japanese and I am unable to add static texts on the Dialog in Japanese. Can anyone provide me a solution, a link to read how implement Japanese support to MFC applications.
Thank you.
|
|
|
|
|
Have a look at This[^]
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
Thanks a lot. I am interested if there is an easier way to do it -> I build a separate version for Japanese language so I do not need multi language support. Just starting a simple MFC Dialog application on which I can add static texts in Japanese.
|
|
|
|
|
|
|
Hi all,
This might be a stupid question, but here goes: When one createa a process, and that process creates a thread. Can that thread monitor the process that created it. Monitor in the sense that the thread can check when a user wants to terminate the process and the thread must deliver a message to the user. I would like to add, what function can I use to monitor a process.
Many Thanx
Regards,
-- modified at 4:39 Thursday 8th March, 2007
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
|
Hello,
I am developping a multithreaded application and I came across a quite complex problem. In brief, suppose that the application can send 'messages' over a communication link (which is pluggable).
In a particular situation, I would like to send a message and wait until I receive a answer (with a timeout). Here is how the CMessage class looks like 9only relevant parts):
CMessage
{
public:
void send();
CMessage* getReplyBlocking(unsigned long timeout);
void setReply(CMessage* pReply);
protected:
HANDLE m_hReplyEvent;
CMessage* m_pReply;
};
So, little explanation: to send the message, we call the send function. This function sends the message over a certain communication link (and we don't really care about how it is implemented). Then, we can call getReplyBlocking to wait for an answer of this message. The communication link, when data is received back, will call the setReply function providing the reply.
Here is the implementation of getReplyBlocking:
CMessage* CMessage::getReplyBlocking(unsigned long timeout)
{
m_hReplyEvent = CreateEvent(NULL,TRUE,FALSE,NULL);
WaitForSingleObject(m_hReplyEvent, timeout);
return m_pReply;
}
Here is the implementation of setReply:
void CMessage::setReply(CMessage* pReply)
{
m_pReply = pReply;
if (m_hReplyEvent != NULL)
SetEvent(m_hReplyEvent );
}
But this design has a some major flaws:
1) If the reply to the message is almost immediate (because for example we plug a test communication link), the setReply function will be called before getReplyBlocking is even called. So, problem: I will wait until I have a timeout and in fact I have already me reply. I could solve partially this issue by first testing if I haven't an answer already (but then, the answer could still be sent between the check and the start of the WaitForSingleObject).
2) To make things more complex, the assignement of the reply may be non-atomic. In fact, to simplify the example I used a simple pointer but in reality, it is a smart pointer. It means that if I have a reply just at the time that my WaitForSingleObject times out, then I am in big trouble (I will start assigning my smart pointer and I will finally return a smart pointer which is not fully constructed).
It must exist mechanisms to solve these kind of problems but I don't really see how I can solve this.
BTW, I am perfectly aware of Semaphores, Critical sections, ... but I failed to see how they can solve these problems (and without introducing new ones).
If somebody has an idea, it will be highly appreciated
Thanks
|
|
|
|
|
This is a nice little communication related problem.
I've come across this problem a few times and I've solved it in a similar way each time.
The best suited solution might depend on the protocol you're using, if it's possible to assign an ID to each message that can be used to map the answer to the request.
I assume this is your case.
It also depends on whether the protocol is asynchronous or not, i.e. if you are able to send multiple requests before you get an answer for the first request.
I assume the protocol is synchronous. Correct me if I'm wrong Cédric.
I'm not sure if I can describe how I've done this without a whiteboard, but I'll try...;)
Usually I have a sending thread that reads from a queue that contains reference counting smart pointers to the messages to be sent. All queues mentioned later contains reference counting smart pointers to message objects, even if i refer to them as "messages".
When a message has been sent that requires a reply I put the message into another queue which is read by a thread (the timeout thread) that handles the timeout, but also waits for incoming messages on a semaphore.
A thread that takes care of the message receiving mechanism puts the received messages into the queue read by the timeout thread and releases the semaphore. This will release the timeout thread which is wating on a reply to the front message from the timeout queue and if the message tags/IDs match I've got a reply for the request sent earlier. The other situation is that the timeout expires in the timeout thread which returns from ::WaitForMultipleObjects(...) with the index of the waitable timer that handles the timeout. Perhaps the request message should be re-sent and put into the sending queue again depending on the protocol used.
If the protocol is asynchronous the timeout thread should perhaps have a local container, e.g. a vector, with messages that can be searched for message IDs when a new message arrives. Messages sent should be put at the end of the vector and the waiting is done on the message at the beginning of the vector.
By using this threading and queueing technique you don't risk losing replies if the are immediate, you can even put a message in the timeout queue before sending it.
Each thread is waiting on synchronization objects such as semaphores and waitable timers.
If you have a look at Joe Newcomer's article about semaphores here[^] you should get an idea of how I release the different threads using semaphores when there are new objects in their queues.
N.B. The above requires an integer member in the CMessage class that contains the timeout value in preferably millisecs. The timeout thread creates a waitable timer.
I hope you get what I'm getting at, but let me know if you don't.
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for your detailed explanation Roger
But I think this will be hard to implement in my application (the design is really different). And also, protocol is totally asynchronous and even, sending messages can be done in different threads.
Anyway, I think I've found a solution. The getReplyBlocking and the setReply functions can be modified in such way:
CMessage* CMessage::getReplyBlocking(unsigned long timeout)
{
WaitForSingleObject(m_hReplyEvent,timeout);
EnterCriticalSection(...);
m_hReplyEvent = NULL;
LeaveCriticalSection(...);
return m_pReply;
}
void CMessage::setReply(CMessage* pReply)
{
EnterCriticalSection(...);
if (m_hReplyEvent)
{
m_pReply = pReply;
SetEvent(hReplyEvent);
}
LeaveCriticalSection(...);
}
The event creation must be done then before sending the message.
Suppose that we call getReplyBlocking and there is a timeout. At this precise time, we receive a message. What could happen: either the message is received just after the WaitForSingleObject (and before we enter the critical section in getReplyBlocking) or we receive the message once we entered the critical section in getReplyBlocking (receiving afterwards is the same scenario).
1) First case: we receive a message at the moment the timeout expired but we didn't enter the critical section in getReplyBlocking, so in setReply we will be able to enter the critical section. The event is still available so we set the reply and we notify it (it will have no impact) then we release the leave the critical section. Then, in getReplyBlocking we enter the critical section, we set the event to NULL and we leave the critical section. The only problem in this situation is that the reply is still set after the timeout expired but honnestly, the times there are largely neglectable.
2) Second case: the message is received when we are already in the critical section of getReplyBlocking. That will force the setReply function to wait until the critical section is left. Then, it will enter its own critical section and check for the reply event. It will be NULL so the reply won't be set.
|
|
|
|
|