What happens when instead of declaring PhEvent_t event; you declare PhEvent_t event = {0};?
I’ve been told that the reason your not seeing the behaviour that you are expecting is
because the event that you are emiting will on be enqueued to a region that has the
same id as that which is soecified in the events collector id. The collector id is
probably being initialized to junk and therefore the event is not going to the places
that you want it to. It’s a problem in our docs. It has been fixed in the QNX 6 docs.
Yes. Here’s the relevent code that executes when coming out
of standby:
----- cut --------
/*
- Emit an expose event to force a complete screen redraw
*/
{
PhEvent_t event ;
PhRect_t rect ;
event.type = Ph_EV_EXPOSE ;
event.subtype = 0 ;
event.flags = Ph_EVENT_INCLUSIVE ; // Tried with zero, too
event.emitter.rid = Ph_DEV_RID ;
event.num_rects = 1 ;
event.data_len = 0 ;
rect.ul.x = rect.ul.y = SHRT_MIN ;
rect.lr.x = rect.lr.y = SHRT_MAX ;
PhEventEmit( &event, &rect, NULL ) ;
}
----- cut --------
My test has one dialog on top of the base window, and the solid
grey dialog background and a label aren’t redrawn.
Previously, Gui Group wrote in qdn.public.qnx4.photon:
Hello Ken
Did you set the emitter id in the event structure to be equal to Ph_DEV_RID?
Thanks
Rodney
Ken Schumm <> kwschumm@qqssoollvv.com> > wrote:
Thanks for the advice, but I haven’t been able to make it work.
I lifted the code I’m using from the PhEventEmit() example, which
is documented as emitting an expose event from the device region.
When this code runs coming out of standby, the base window does
update properly, but any windows/dialogs that are overlaid on the
base window remain partially undrawn.
Is the example code incorrect?
Previously, Gui Group wrote in qdn.public.qnx4.photon:
Sorry, just have one other thing to add
Gui Group <> gui@qnx.com> > wrote:
Hello Ken
If you emit an expose event when you come out of standby mode, it will cause
everything to redraw. This should solve your problem.
You have to emit this event from the device region ( Ph_DEV_RID ).
Thanks
Rodney
Thanks
Rodney
Ken Schumm <> kwschumm@qqssoollvv.com> > wrote:
We have a photon based embedded instrument that implements
a low-power standby mode.
The video card is an Ampro MiniModule II pc/104 model.
When the instrument goes into standby, we write a value to
an i/o port which places the video in a hardware suspend
mode. Per the Ampro docs, suspend mode is “a very low power
mode in which the display and CPU access to the video
controller are suspended, though the video memory content
is maintained”. It also turns off our LCD backlight.
Entering and exiting suspend mode works, with a glitch. Some
of the Photon widgets are not redrawn when exiting suspend.
If video memory is truly maintained, then I can’t see the
need to redraw, but so it goes.
What is the best way to force the existing screen widgets to
all be redrawn in their current state and position?
I have tried a PtReRealizeWidget() on the base window and
that doesn’t seem to redraw the base window background and
all the overlaid windows.
Do I need to track each displayed widget and PtReRealizeWidget()
each one of them? There’s gotta be a better way.
TIA
\
).