|
see my replies to Chris Loslinger above.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
The problem is that operator*(MyFunc) is ambiguous, whereas operator->*(MyFunc) is not. You may have missed the point that this->*pProc is not equivalent to this->(*pProc) or (*this).(*pProc). neither of the latter versions would compile, because they are just as ambigous as (*pProc)!
A member function pointer isn't simply an address, it is a small struct that contains various bits of information that are needed to determine the actual function address, depending on whether the function is static, inline, virtual, or ordinary, whether the function type was defined in a base class or not, and maybe other factors as well. The compiler therefore wouldn't be able to tell if by invoking operator* you want to access these struct members, or rather call a function whose address is encoded by that struct!
At least that is my (incomplete) understanding of the matter. I may not be entirely correct, but you're free to google for more details. I've found 'Pointers to member functions' a very insightful article on the matter, although I couldn't pinpoint a concise answer to your question in there.
P.S.: I've just thought to search for this topic on CP and found this article. Just like the above link it explains a lot about member function pointers and their (lack of) use, but you might not like the article as much because it makes a point of how utterly useless member function pointers really are, except for the one thing this article is about: fast delegates. 
modified on Wednesday, September 14, 2011 5:25 AM
|
|
|
|
|
Thanks, thats the first good answer. 
==============================
Nothing to say.
|
|
|
|
|
Hi,
I'm running into a problem that I've been puzzled for 2 days already. If anyone has any suggestion on how to trace it, I truly appreciated.
I have a MDI application with multiple tabs in MyView. I also have a panel which list files and folders from My Computer.
I can drag a file from the panel onto any tabs in MyView and it would accept the drop. However, if I drag a file from my desktop or anywhere outside of my application, the + sign shows up like it's trying to accept drop, but when I drop the file, OnDropFiles event doesn't get triggered at all.
I've check that I have ON_WM_DROPFILES()in BEGIN_MESSAGE_MAP, DragAcceptFiles() in the OnInitialUpdate, afx_msg void OnDropFiles(HDROP hDropInfo) in the header file.
Switching to OleDragDrop also behaves the same way...If I didn't setup properly, it wouldn't even work when I drag the file from the panel, right? I'm really running out of ideas on how to tackle this one.
Any ideas would be tremendous help to me~~
Thanks,
Helen
|
|
|
|
|
If i may suggest, instead of relying on wM_DROPFILES and DragAcceptFiles, rather use DoDragDrop[^], RegisterDragDrop[^] / RevokeDragDrop[^]. As i know, WM_DROPFILES is the "old" method of doing this.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
modified on Monday, September 12, 2011 4:37 AM
|
|
|
|
|
Thanks for your reply~~ I'll give it a shot. Do you know what might have caused the drop event to only get triggered from the same application but not from outside the application?
|
|
|
|
|
I found out what caused the problem, hopefully this will help others who is also struggling on the same issue.
Just have to turn off the UAC control in the project property. I guess it makes sense, because I can accept drop files
within my own application but not from outside.
Thank you code-o-mat for helping~
Helen
|
|
|
|
|
Hi...
I have a program to read data from serial port,and I want to repeat the program every 1 microsecond.
this is my program, but I just can repeat every 1 milisecond
void CStripDlg::OnTimer(UINT nIDEvent)
{
int dcount=0;
CString data[4];
VARIANT in_dat;
{
in_dat = m_comm.GetInput();
CString strInput(in_dat.bstrVal);
m_input.Format("%s", strInput);
m_comm.SetInBufferCount(0);
}
}
UpdateData(FALSE);
CDialog::OnTimer(nIDEvent);
void CStripDlg::OnStart()
{
SetTimer(1,1,NULL);
}
}
thx
|
|
|
|
|
See here and here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
thank you, for your suggestions
|
|
|
|
|
You 'millisecond' timer is already (as David already suggested) an illusion: Windows doesn't provide millisecond accuracy. In any case you shouldn't need microsecond time-scale for dealing with serial port communications.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
thank you, for your suggestions
|
|
|
|
|
Clock granularity on Windows is about 9 milliseconds. And thats if you are lucky. It is not a real time OS, so even that is not guaranteed. Especially form user mode. If you have any kind of hardware activity your user mode thread is going to get slung off the CPU.
Even in the kernel you cant get this kind of timing, the granularity is the same, and although their threads have higher priority than user mode, any kind of interrupt or dispatch level activity is also gong to suspend your thread.
It is quesitonable whether you want 1 microsoecond timing; the clock rate of the UART is probably not that fast (thnik 115200 bps), and that's per bit. The UART is going to asemble those into bytes, dividing the speed by at least 8 (depending on start and stop bits), and pack them in a buffer (if the UART hasnt got a receive buffer its a really shonky piece of HW). FFIOs are normally 8 bytes minimum so your rate of needing to service the receive data on the UART is divided by another 8.
What is the problem you are trying to solve here? Perhaps if you told us that we can offer some advice.
==============================
Nothing to say.
|
|
|
|
|
thank you, for your suggestions
|
|
|
|
|
microcontroller send data every 2 ms, my problem when the microcontroller gets the input, the program can not display the data directly, but must read the entire remainder of the data in the buffer.
this is setting port, and recevied data. I use Microsoft Communication Control
TRY
{
m_comm.SetCommPort(12);
m_comm.SetSettings("9600,N,8,1");
m_comm.SetInputLen(1);
m_comm.SetRTSEnable(FALSE);
m_comm.SetRThreshold(0);
m_comm.SetPortOpen(true);
UpdateData(FALSE);
MessageBox("Port opened successfully");
}
CATCH(CException, e)
{
MessageBox("Error opening port");
}
END_CATCH
so I use the clear buffer to clear the buffer. but rather the execution time becomes slow and missing data
m_comm.SetInBufferCount(0);
}
can you offer some advice?
|
|
|
|
|
What sort of HW is it, Who makes it? Doesnt it come with a proper driver or some other interface to the system?
I cant believe any firm can sell HW that is pumping data that quick to a com port, it just isnt going to get serviced in windows.
Is there perhaps a configuraiton to the device whereby you can increase the receive buffer or some such?
==============================
Nothing to say.
|
|
|
|
|
You need to do the following.
1. Determine the actual baud rate. In your other code you suggested 9600. Presumably that is correct.
2. Create a thread.
3. That thread does the following and NOTHING else.
a. Block on the serial port. (You don't use a timer but rather you wait until data is available.)
b. Read one byte
c. Add that byte to a thread safe queue.
d. Go back to a.
4. In your GUI code (or wherever) you read data from the queue and do whatever you want with it. Note that this occurs in a different thread.
|
|
|
|
|
Where's the 'Great Answer' button?
My 5.
|
|
|
|
|
jschell wrote: b. Read one byte
You want to read the FIFO taking out as many bytes at a time as you can. It is only for special control characters that you need to read individual bytes, such as DTR RTS CTS etc etc etc and you set those in the 'wait on mask'.
==============================
Nothing to say.
modified on Tuesday, September 13, 2011 3:16 AM
|
|
|
|
|
Few months back I was having the same issue of Microsecond. Windows does not provide granularity of 1 microsecond. For this reason we have used Real Time OS which is an extension to Microsoft Windows . The Timer granularity is well handled by RTOS ( provides upto 1 Microsecond , which can further modified by modifying the value of 'Ticks' of clock using some API of that RTOS.
|
|
|
|
|
you have any articles or sample programs?and Can I ask articles or sample program?
|
|
|
|
|
Fat__Eric wrote: You want to read the FIFO taking out as many bytes at a time as you can
I presume my answer wasn't clear.
If you block on a read and there is in fact data available then you do not block. So many bytes are read.
And a serial port is a single byte stream. So excluding an intermediate buffer mechanism it is only going to read one byte at a time.
But if the API supports a buffered read then using that is certainly an option.
|
|
|
|
|
okey, thanks
do you have sample program?
modified on Wednesday, September 14, 2011 1:17 AM
|
|
|
|
|
jschell wrote: And a serial port is a single byte stream. So
Very very few are. As stated a single byte rcv buffer UART is a very shonky piece of hardware. The stock (what is it, 82530 or some such compatible UART on most PCs) has an 8 byte RX FIFO.
Better quality UARTs on serial PCI cards will have far bigger FIFOs.
==============================
Nothing to say.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
