sorry for the silly question(s), but I cannot get out of it!
I am writing a simple application that just displays
data gathered (via shared memory) from another process.
I use PtText to display data and PtTextModifyText inside an infinite
loop to modify the text itself.
The question is: where do I put the function call?
If I attach a callback to the window opening, data will never be
displayed, the only chance seems to have a custom mainloop instead of
the PtMainloop() provided by photon, but this is unreccomended in the
manuals.
And also if a give a .cpp extension to a function callback a get weird
messages at compile time. Where am I wrong?
Any help much appreciated!
Francesco
Previously, Francesco Jatta wrote in qdn.public.qnx4.photon:
sorry for the silly question(s), but I cannot get out of it!
I am writing a simple application that just displays
data gathered (via shared memory) from another process.
I use PtText to display data and PtTextModifyText inside an infinite
loop to modify the text itself.
The question is: where do I put the function call?
If I attach a callback to the window opening, data will never be
displayed, the only chance seems to have a custom mainloop instead of
the PtMainloop() provided by photon, but this is unreccomended in the
manuals.
Two choices pop to mind:
- Create an Idle function with PtAppAddWorkProc, and put your PtText
update in there. It will consume a lot of CPU, and is generally
not a good thing to do. PtAppAddWorkProc is meant for temporary
CPU-intensive activities.
- Create a proxy, and attach a callback to it using PtAppAddInput.
Whenever your other program puts new data into shared memory, have
it Trigger() the proxy. Your Photon app must tell the data
acquisition app which proxy to Trigger. Put your PtText update in
the callback you attach with PtAppAddInput.
Solution 2 is infinitely better than solution 1 in my opinion, as it
uses only enough CPU to update the screen when necessary, and the
latency between data acquisition and display is minimized.
And also if a give a .cpp extension to a function callback a get weird
messages at compile time. Where am I wrong?
It’s not a C++ file. It’s a C file and wants a C extension. You
might be able to compile with C++ if you liberally sprinkle
extern “C”
throughout your code.
Cheers,
Andrew
“Andrew Thomas” <Andrew@cogent.ca> wrote in message
news:Voyager.010209132209.67985456E@andrewhome.cogent.ca…
Previously, Francesco Jatta wrote in qdn.public.qnx4.photon:
sorry for the silly question(s), but I cannot get out of it!
I am writing a simple application that just displays
data gathered (via shared memory) from another process.
I use PtText to display data and PtTextModifyText inside an infinite
loop to modify the text itself.
The question is: where do I put the function call?
If I attach a callback to the window opening, data will never be
displayed, the only chance seems to have a custom mainloop instead of
the PtMainloop() provided by photon, but this is unreccomended in the
manuals.
Two choices pop to mind:
- Create an Idle function with PtAppAddWorkProc, and put your PtText
update in there. It will consume a lot of CPU, and is generally
not a good thing to do. PtAppAddWorkProc is meant for temporary
CPU-intensive activities.
- Create a proxy, and attach a callback to it using PtAppAddInput.
Whenever your other program puts new data into shared memory, have
it Trigger() the proxy. Your Photon app must tell the data
acquisition app which proxy to Trigger. Put your PtText update in
the callback you attach with PtAppAddInput.
- Create a PtTimer widget as a child of the main window, attach a callback,
and do the update in that callback. It’s better than 1), because you can
control the update frequency
And also if a give a .cpp extension to a function callback a get weird
messages at compile time. Where am I wrong?
Just use the extension .cc for your c++ files. .cpp is not recognized.
Markus
To compile a .cpp file, add this to your makefile. I’ve got it as the
second line of actual code, right after “include …/include/make.cfg”
and before anything else.
.SUFFIXES: .cpp
.cpp.o:
$(COMPILE.c) $<
Meredith
Markus Loffler wrote:
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:> Voyager.010209132209.67985456E@andrewhome.cogent.ca> …
Previously, Francesco Jatta wrote in qdn.public.qnx4.photon:
sorry for the silly question(s), but I cannot get out of it!
I am writing a simple application that just displays
data gathered (via shared memory) from another process.
I use PtText to display data and PtTextModifyText inside an infinite
loop to modify the text itself.
The question is: where do I put the function call?
If I attach a callback to the window opening, data will never be
displayed, the only chance seems to have a custom mainloop instead of
the PtMainloop() provided by photon, but this is unreccomended in the
manuals.
Two choices pop to mind:
-
Create an Idle function with PtAppAddWorkProc, and put your PtText
update in there. It will consume a lot of CPU, and is generally
not a good thing to do. PtAppAddWorkProc is meant for temporary
CPU-intensive activities.
-
Create a proxy, and attach a callback to it using PtAppAddInput.
Whenever your other program puts new data into shared memory, have
it Trigger() the proxy. Your Photon app must tell the data
acquisition app which proxy to Trigger. Put your PtText update in
the callback you attach with PtAppAddInput.
-
Create a PtTimer widget as a child of the main window, attach a callback,
and do the update in that callback. It’s better than 1), because you can
control the update frequency
And also if a give a .cpp extension to a function callback a get weird
messages at compile time. Where am I wrong?
Just use the extension .cc for your c++ files. .cpp is not recognized.
Markus
-
Create a proxy, and attach a callback to it using PtAppAddInput.
Whenever your other program puts new data into shared memory, have
it Trigger() the proxy. Your Photon app must tell the data
acquisition app which proxy to Trigger. Put your PtText update in
the callback you attach with PtAppAddInput.
-
Create a PtTimer widget as a child of the main window, attach a callback,
and do the update in that callback. It’s better than 1), because you can
control the update frequency
There is a trade-off:
(1) When the data refresh rate is too slow, it is better to trigger a proxy to
notify
an observer process to fetch data.
(2) When the data refresh rate is too high, it is better to have a PtTimer which
you
can control your sample rate.
Regards
–
WeiBing Tong
Aquila Mining Systems Ltd.
1450 City Councillors, Suite 330
Montreal, QC
Canada H3A 2E6
Tel: (514) 874-9917 ext 239
Fax: (514) 874-4005
Email: wbtong@aquilamsl.com