|
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.
|
|
|
|
|
Cedric Moonen wrote: Thanks for your detailed explanation Roger
You're most welcome Cédric.
Sorry about the delay but I went out for lunch and I actually had to work for a while...
Just some thoughts, do with them as you please...
Cedric Moonen wrote: And also, protocol is totally asynchronous and even, sending messages can be done in different threads.
Regarding sending from multiple threads I solve this by having a thread that takes care of the sending mechanism as I described earlier. When messages are placed in the send queue it is of course locked with a critical section so multiple threads can "send" messages. After unlocking the queue the corresponding semaphore is released unleashing the send thread that actually transmits the data over the desired carrier.
Regarding the protocol being asynchronous I wonder how you're going to solve it since you're calling CMessage::getReplyBlocking(...) which would block the thread until the timeout expires or a suitable reply is received. During that time you would be unable to send any messages, at least from that thread. This also suggests that you're only sending messages from worker threads since you're not processing windows messages during waiting for replies so you cannot send a message from the main thread that waits for a reply. I sense small warning signs here about the design but it's not alarming.
Regarding the two scenarios at the bottom of your post I consider both of them to be describing a timeout situation for a request. If you discard the message or not makes no difference in my opinion since the message was received too late which usually should be treated the same way as if there was no reply. In this situation perhaps the message should be re-sent depending on the protocol used.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Regarding the protocol being asynchronous I wonder how you're going to solve it since you're calling CMessage::getReplyBlocking(...) which would block the thread until the timeout expires or a suitable reply is received. During that time you would be unable to send any messages, at least from that thread. This also suggests that you're only sending messages from worker threads since you're not processing windows messages during waiting for replies so you cannot send a message from the main thread that waits for a reply. I sense small warning signs here about the design but it's not alarming.
I totally agree. Except that I'm not developing a GUI application at all
It's kind of complicated to explain but I'll try . In fact this application (console application) is spawned by a Java application (and the console window is even not visible because Java will take the stdin and stdout for itself). The application provides a way to access 'parameters' to this java application. And they speak together by using Corba (the stdin and stdout are only used to exchange information about the corba "connectors"). And, if we want to retrieve the value of a parameter in java, the call will go through corba, and will have for effect that a message needs to be sent on a communication link. Thus, you can have several parameter requests issued from different threads.
|
|
|
|
|
Java and Corba? 
I dont' envy you one bit.
It may be that I'm not getting exactly what you're trying to do, but I think I understand the big picture.
It feels like you have an external thing that you want to use from the Java app and you're providing the link between the Java app and the external thing.
I hope you have considered a COM component and ruled that solution out because of limitations in the Java app...
There's one thing that I don't get:
In the light of your latest post I interpret your original post to be about the communication between the console app and the external thing. How do you communicate with the console app from the Java app to be forced to have multiple threads in the console app since the console app runs in a process of its own? Or is this a protocol issue from the external thing point of view like keep-alive messages?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Java and Corba?
I dont' envy you one bit.
In fact I'm not working really on the Java side, mainly on the native side. But I agree, Corba is kind of 
Roger Stoltz wrote: I hope you have considered a COM component and ruled that solution out because of limitations in the Java app...
I didn't select the technology but this has to run on several platforms (like Windows CE for example). As far as I understood, COM was not an option for the Java side.
Roger Stoltz wrote: How do you communicate with the console app from the Java app to be forced to have multiple threads in the console app since the console app runs in a process of its own?
Well, the console app is in fact a kind of server that provides parameters that can be used by different clients through a corba connection. So in this way it needs to be multithreaded.
And of course the Java application can also request the same parameter on different threads.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
.