|
Is it possible to set priority to the callback function?
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Nope. (anyway, please, be more specific).
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]
|
|
|
|
|
I thought, If possible I want to set high priority to callback which gets MIDI message and keep the MIDI message processing thread priority default(normal).
Otherwise, I need to set below_normal to processing thread.
Thanks for your help!!
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
That way you only hit the target if the callback it's called by different thread.
BTW: Why do you need it?
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]
|
|
|
|
|
Hi,
The callback get MIDI message and write into ring buffer after that it wakeup processing thread using event.
Sometimes when callback got more than one message, it writes in ring buffer and wakeup processing thread many times.
This time, If the callback is on writing a message from MIDI to ringbuffer and processing thread think this message is complete and reads by incrementing pointer.
If processing thread does it faster, it goes one byte beyond actual message(not complete) written by callback then callback get "buffer overrun" condition.
Thats why now, I made processing thread priority below normal and seems working.
Thanks,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
I think adjusting thread priority is not a reliable fix for the flaw on your syncrhonization mechanism.
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]
|
|
|
|
|
Hi,
Me too think so, even though it seems working, It would be better If I fix it in some other proper way and not by just priority or timing.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
I didn't fully understand what you were saying but I understood that the problem was because your buffer was accessed by two threads and you have problems when one is writing in it while the other is reading it (which is logical). If that's your problem, why don't you access the buffer in a critical section ? This way, only one thread will be able to access the buffer at a time and this will avoid having data corruption.
|
|
|
|
|
Hi,
I will try If I can use critical section.
Problem is data is written into a single ring buffer.
If I use critical section, then other thread cannot access any part of ring buffer until write finish.
I want to let other thread to read the messages written completely by write thread(callback) and not current message being written.
One way is, I can check write pointer location, if the message not complete, then reset the read pointer to current message starting byte and check for complete message again.
Thanks for your help, I will try this tomorrow in office and update after I fix it.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Another option is to update the write pointer only when you have written your message completely.
|
|
|
|
|
Cedric Moonen wrote: Another option is to update the write pointer only when you have written your message completely.
Hi,
It is fixed now by your idea and there is no overrun.
Thanks for your great suggestion!!
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Hi,
I am facing a problem while accessing values in a std::list in release build. The code I am using is like
struct _STRUCT_ABC
{
int iIdCount;
string szName;
}STRUCTABC, *PSTRUCTABC;
list<<PSTRUCTABC>>:: iterator ittr = g_ABCList.begin(); // g_ABCList is a golbal list with PSTRUCTABC
int iCount = ittr._Ptr->_Myval->iIdCount; // Works fine with _DEBUG prepocessor but does not work in release mode if _DEBUG prepocessor is not defined.
Now according to VS2005 compiler _Ptr is a private variable if _DEBUG is not defined. In that case how to access the values inside the list?
Thanks in advance.
|
|
|
|
|
Aryan S wrote: int iCount = ittr._Ptr->_Myval->iIdCount;
you don't like the public interface of the list (and its iterator), do you?
int iCount = ittr->iIdCount;
int iCount = (*ittr)->iIdCount;
[thanks to]
Cedric's post
[/thanks to]
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]
modified on Monday, June 23, 2008 5:32 AM
|
|
|
|
|
What are you doing  ?
That's not the way to work with iterators. You hsould simply dereference them:
int iCount = (*ittr)->iIdCount;
|
|
|
|
|
Thanks!!!
I am actually new in this field... 
|
|
|
|
|
Aryan S wrote: I am actually new in this field...
There are a lot of tutorials on the web, it would be much more efficient to read some of them before going any further developing code with tools that you don't how to use.
Check this[^] for instance.
|
|
|
|
|
I have a few controls like button , list box and combo box on my dialog in a dialog based application. I use tab key to change focus on controls hence the OnkIllFocus for the controls is executed as i tab . But When i close the dialog OnkIllFocus for the last control having the focus is not executed.I want to know the reason why this happens .
I expect the current control having focus shud lose Focus on closing Dialog hence OnkIllFocus for that control shud be called.If i am wrong plz correct me.
|
|
|
|
|
Shaileshhex wrote: I want to know the reason why this happens .
Maybe because the WM_KILLFOCUS message is not generated at that point. Use Spy++ to verify.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello, everybody. There is a such problem: it is impossible to process the 2-dimens. array, no problems arise when i allocate memory using malloc, but next lines of code brings computer to stop:
for(row=0; row<=2303; row++){
for(col=0; col<=3071; col++)
Arr[row][col]=....;
}
mmm..How solve this?
|
|
|
|
|
Rustik wrote: but next lines of code brings computer to stop
What do you mean ? Your computer really stops  ? Or your program just crashes ?
How is your array declared ? Are you sure you don't go outside the bounds of your array ? Remeber that C arrays are 0 indexed.
|
|
|
|
|
Declaration: int ArrayName[rowSize][colSize]={{0},{0}};
...excuse me for my bad english, i mean program crashes.
|
|
|
|
|
Your program possibly crashes because your array size exceeds the stack one. Try to use the heap, instead.
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]
|
|
|
|
|
it's not clear. Plz explain.
|
|
|
|
|
the size of your array (assuming its elements are int) is 2304 * 3072 * sizeof(int)= 2304 * 3072 * 4 = 28311552 bytes, while the default stack size for an application is (according to MSDN [^]) 1 Megabyte, i.e. 1048576 bytes.
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]
|
|
|
|
|
Unfair damn voting[^] 
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
