|
Are you trying to pass multimedia timer events into your window handling code or the other way round?
If it's the first option and you're using timerSetEvent , you could do this:
- For each timer events, create a kernel event.
- Create the the timer event using the flag
TIME_CALLBACK_EVENT_SET and pass the kernel event handle as the callback procedure. - Create a thread with a function that (in a loop) does a
WaitForMultipleObjects , waiting for any one of the kernel events set by the timers. - When an event is detected in the thread function, POST a window message as appropriate.
The general pattern of setting kernel events with timer events allows you to transfer the timer event into another thread.
BTW - do you realise that the multimedia timer API is obsolete and could easily disappear soon? You might be better off using timer queues (see this article for a description[^]) that, as far as I can tell, have the same resolution and accuracy as multimedia timers. Also, it looks like they're better tied into the Windows synchronisation functionality.
|
|
|
|
|
Stuart Dootson wrote: do you realise that the multimedia timer API is obsolete and could easily disappear soon?
Hi Stuart,
Where did you hear that? Link?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Hi Stuart,
Where did you hear that?
I told him.
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]
|
|
|
|
|
So where did YOU hear that?
I don't see any indication that the multimedia timer APIs are deprecated.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: So where did YOU hear that
If I remember well, Stuart Dootson told me.
Mark Salsbery wrote: I don't see any indication that the multimedia timer APIs are deprecated.
Because we should keep it secret.
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]
|
|
|
|
|
CPallini wrote: Because we should keep it secret.
ok. shhhhh
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
CPallini wrote: Because we should keep it secret
But now you've let the cat out of the bag!!! The boys'll be round to sort you out
|
|
|
|
|
It's only me....I won't tell anyone!
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Wow the cat is out, hence is alive: we should tell to Mr. Schroedinger...
(or is the above another secret?)
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]
|
|
|
|
|
|
Excellent! Thank you
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You are required to implement a C preprocessor. The Preprocessor is to be implemented as a command-line tool, the input to which is a C source file (.c extension) and the output is the preprocessed file (.i extension). The tool also takes several options.
$ cppr <options> file.c
On successful processing, file .i is produced.
<options> may be:
Preprocessor options-
-Aassertion -C -dD -dM -dN -Dmacro[=defn] -E -H
-idirafter dir -include file -imacros file
-iprefixfile -iwithprefix dir -M -MD -MM -MMD
-nostdinc –P -Umacro –undef
Directory options-
-Bprefix -Idir -I-
Implement any two of the above.
These are the options defined by the gcc compiler. You must implement the following features at a minimum:
i. Stripping off of comments
ii. #ifdef and #endif
iii. #define for constants (not macros)
COULD U PLEASE HELP ME DOING THIS PROJECT?
|
|
|
|
|
Cassendra wrote: COULD U PLEASE HELP ME DOING THIS PROJECT
I could, but 1) I dont do homework, 2) you couldnt afford me
Why dont you ask yourself some questions about
1) how you might get a program to recognise 'c' code
2) how you might use the results from (1) to perform the various tasks ..
since its almost xmas and despite doing what I thought was my last good deed of the year (84Km charity cycle on Sunday, giving blood on Wed), Im going to suggest you read these as a start :-
http://www.ibm.com/developerworks/aix/library/au-c_plusplus_antlr/index.html [^]
http://mcpp.sourceforge.net/[^]
they should give you some ideas ... you might also want to check out the posting guidelines at the top of the forum
'g'
|
|
|
|
|
Thanks for your suggestions.
MERRY CHRISTMAS.
|
|
|
|
|
I think you've got the wrong forum, jokes belong in The Lounge
|
|
|
|
|
Your is good, however.
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]
|
|
|
|
|
Ppl started posting their question papers!
|
|
|
|
|
I found a free ANSI C parser with source code - Gold Parser[^]. You could download the source as well. You can look at the source and tune it for a preprocessor and generate the .i file. I hope it will be useful for you.
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
Hi All,
I am porting a VC++ 6.0 to VC++ 9.0
I am getting the LNK error when i tried to pass a iterator as a function parameter.
Here is the code.
void CMemTable::TestIterator( std::list< CString >::iterator it)
{
std::list< CString >::iterator itLocal;
itLocal = it;
}
CMemTable pTable;
std::list<cstring>::iterator test;
pTable->TestIterator(test);
error LNK2019: unresolved external symbol "public: void __thiscall CMemTable::TestIterator(class std::list<class>>,class std::allocator<class>>>::_Iterator<1>)"
All suggestions are invited.
Thanks you.
|
|
|
|
|
The coded you've posted wouldn't compile - pTable is an object, but you're calling TestIterator using 'pointer to member' syntax.
I'm wondering - does the signature of the declaration of TestIterator (in the CMemTable class declaration) exactly match the signature of the method's definition?
|
|
|
|
|
pratap1980 wrote:
pTable->TestIterator(test);
In other words, make it pTable.TestIterator(test);
OK,. what country just started work for the day ? The ASP.NET forum is flooded with retarded questions. -Christian Graus
Best wishes to Rexx[^]
|
|
|
|
|
Here is my problem:
I want access to the CPropertySheet parent window so that when I define a list control dynamically in one of its property pages, that list control (and its movement) is tied to the parent CPropertySheet.
I want to do this so that I can "share" one CListCtrl between 2 or 3 property pages.
Here is what I have:
CMyPropSheet
CSettingsPage2 *m_pPage2;
m_pPage2 = new CSettingsPage2;
AddPage ( m_pPage2 );
property page
CSettingsPage2::CSettingsPage2()
: CPropertyPage(CSettingsPage2::IDD)
{
}
void CSettingsPage2::DefineList()
{
g_MyCListCtrl.Create ( dwStyles, rLocRelative2Page, pPropSheet, IDD_SOME_CONSTANT );
}
The one CListCtrl lists items that must appear in 3 property pages - each of the 3 pages will reveal different attributes of the list's items. I know design could be different to accomplish the same, but I want it this way.
Thank you very much!
John John
|
|
|
|
|
Not sure that you can do that - each different property page is a different dialog template, so has different controls.
The easiest way is just to have a separate list control on each page that contains the same items? If the three pages all have a reference to the same (externally contained) set of data, that's much easier than messing around trying to get the same list control on each page.
Alternatively...(and this is something I was discussing with one of my developers today) you could just have one dialog, with a tab control on it. When you select different tabs, you show/hide controls to match the activated tab.
|
|
|
|
|
Why can't you pass the CPropertySheet pointer to CSettingsPage2's constructor and keep it as a member variable? for instance,
CSettingsPage2::CSettingsPage2( CPropertySheet* pPropertySheet )
: CPropertyPage(CSettingsPage2::IDD),
m_pPropertySheet( pPropertySheet )
{
}
While creating the property page,
m_pPage2 = new CSettingsPage2( this );
AddPage ( m_pPage2 );
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
I am trying this right now, but I am not sure of what I need to account for.
is the Constructor simply:
CSettingsPage2::CSettingsPage2( CWnd* pParent )
: CPropertyPage(CSettingsPage2::IDD)
{
m_pParentWnd = pParent;
}
Then when I create each page
m_pPage2 = new CSettingsPage2( this );
What I am also thinking I need to consider is when I move the entire property sheet window. Since my CListCtrl was tied to the parent property sheet, would my g_MyCListCtrl move just as it would have if separate instaces were created on each page and tied to those pages?
Also, what would the Z-order be of g_MyClistCtrl with respect to other pages (don't want it hidden when it should be active in Page2 (and elsewhere).
Thanks for the input.
|
|
|
|