Whoops — In item 2 make that non-opaque…
Because this didn’t work I came up with the following: Leave the
region Non-Opaque which means you will recieve 2 events for each
^^^^^^^^^
actual event. The first is the raw event and the second is cooked one.
–Bill
William M. Derby Jr. <derbyw@derbtronics.com> wrote:
On 10 Jan 2001 16:16:26 GMT, Norbert Black <> nblack@qnx.com> > wrote:
Frankly the “INPUTGROUP” thing is a bit of a
mystery to me – what exactly is its purpose?Erm… You know, I should know… I know
that an “input group” is a collection of physical
mouse/keyboard/touchscreen/whatever associated with a single
user. By grouping them, we allow for screening (lightbulb goes
on) - on where the events are coming from. D’oh!You know, you could filter based on the input_group member of the
event. Remote connections can be forced into a new input group
(phditto takes a -i, for instance)…
This doesn’t quite wok out.
I know this is a typo, but I have this bizarre vision of you
competing in the “Iron Chef” competition, software category… 
if you start phditto with a -i for an
input group that doesn’t exist – it just complains that it doesn’t
exist and refuses to start up… I then tries the -u option which is
supposed to create a new input group and… The “-u” option
appears broken. It doesn’t create the second pointer on my system as
the documentation states – matter of fact it seems to have no effect
at all…
sigh Garry? Anybody? As I may have said before, I’m out on
the edge of my experience base here… 
With that in mind I have created a variartion of the PhRegionOpen
example which puts region up and draws rectangles which follow the
mouse as it moves over the region. I have created the “filter” region
on the dev side and actually have the thing working.
Well done, that man.
The example will
handle key and pointer events (ESC exits) and the color of the
rectangle will change delpending if you are local or remote.There are some odd quirks though…
- The filter region must specify a region rect. but as long as the
rect in non-zero the size doesn’t matter - i.e.; you get all PTR and
KBD events…
Don’t ask me, boss. Hopefully the real expert in this will
finally get back from Las Vegas soon…
- You must register for RAW events and you must NOT make the region
OPAQUE to the RAW events. (i.e. suddenly ALL input is gobbled up and
you must use another node to terminate the program.)
Yep – that I’d expect. That’s OPAQUE by definition, right?
No event goes past a region that is OPAQUE to it.
My Idea was to change the input_group field of the event and re-emit
it- but I don’t seem to be able to re-emit the event and have it do
anything…is there some trick to re-emiting a raw event?
Souldn’t be? Here’s a bit of sample code that emits a raw key
event directly at the device region:
***************** begins *******************************
int keyname;
PhEvent_t event;
PhRawKeyEvent_t data;
PhRect_t rect;
sleep(3); /* give time for user to change focus */
memset( &event, 0, sizeof( event ) );
memset( &data, 0, sizeof( data ) );
event.type = Ph_EV_RAW;
event.subtype = Ph_EV_RAW_KEY;
event.emitter.rid = Ph_DEV_RID;
event.collector.rid = Ph_DEV_RID;
event.flags = Ph_EVENT_DIRECT;
event.input_group = get_input_group( NULL );
event.data_len = sizeof( data );
event.num_rects = 1;
/* the event’s rectangle covers the entire event space, saves us from
finding out the extent of the collector’s region */
rect.ul.x = rect.ul.y = SHRT_MIN;
rect.lr.x = rect.lr.y = SHRT_MAX;
keyname = ApName( widget );
/* Pk_* macros are from /usr/include/photon/PkKeyDef.h /
if( keyname <= ABN_base_btn_key0 )
{
/ set data.key_cap as a value from Pk_0 to Pk_9 */
data.key_cap = (ApName( widget ) - ABN_base_btn_key1) + 1;
if( data.key_cap == 10 )
data.key_cap = 0;
data.key_cap += Pk_0;
}
else if ( keyname == ABN_base_btn_keyF1 )
{
data.key_cap = Pk_F1;
}
data.key_sym = data.key_cap;
data.key_mods = 0;
/* emit key down */
data.key_flags = Pk_KF_Sym_Valid | Pk_KF_Cap_Valid | Pk_KF_Key_Down;
PhEventEmit( &event, &rect, &data );
/* emit key up */
data.key_flags |= ~(Pk_KF_Key_Down | Pk_KF_Sym_Valid );
PhEventEmit( &event, &rect, &data );
****************** ends ********************************
This is Photon 2.0 code, by the way. Note in particular that you
must not have Pk_KF_Sym_Valid set on the key up, otherwise you
will seem to get two key events.
Because this didn’t work I came up with the following: Leave the
region Opaque which means you will recieve 2 events for each
actual event. The first is the raw event and the second is cooked one.
Hmmmmm. This sounds fishy. Are you sure that you have your
region between the Device region and the region owned by phrelay?
The former is supposed to eat all the raw key and ptr. events
once they reach it.
- For some reason I get the local (Input) KBD and PTR events and
phrelay KBD events but do NOT get phrelay PTR events – this is really
bizarre… To get my stuff to work I had to make the remote/local flag
always reset to REMOTE so that when cooked messages showed up with no
corresponding raw event they would be handled correctly…
Any clues here?
Symptom of what, I do not know.
I put my example on my FTP site if you want to try it
Thanks, but I’m probably not going to get a chance today. (Heck,
I shouldn’t really be typing this… )
Let us know how all of this shakes out, and maybe I can catch a
later iteration?
Norbert Black
QSSL Training Services
On 11 Jan 2001 16:15:16 GMT, Norbert Black <nblack@qnx.com> wrote:
I know this is a typo, but I have this bizarre vision of you
competing in the “Iron Chef” competition, software category… >
Bill’s choice of a while loop is suprising but I don’t think it works
in the program. Yes - it’s too spicy for my tastes…
But the Iron Chefs use of conditional statements
is very good…yes…I really like this…
The Iron Chef wins again…
Souldn’t be? Here’s a bit of sample code that emits a raw key
event directly at the device region:
Just what the doctor ordered… The completed filtering example
is at ftp.derbtronics.com as remote.c and remote.read. It now does
everything it’s supposed to.
Now that I can re-emit events and make the region opaque I have
removed the stupid global variables and race condition stuff and set
a bit in the flags area of the PTR and KBD events - I went though
the header files and picked bits that were far from anything defined.
I needed to use the flags because other stuff is clobbered as it goes
through the device region.
Is there any chance I can get these or some other flag bits reserverd?
(as USER flag bit or some such thing?)
By using the flags you could actually make the filter region and
handler a seperate program since the flags member now contains the
local/remote payload… It works quite nicely and is completly
decoupled from the front end app.
BTW I tried using the “zero” field and it was passed through on KBD
events but clobbered on PTR events – go figure…
If you do put this on QDN please also put it up as a region example –
There is a real darth of information/examples on doing stuff at this
level.
–Bill
William M. Derby Jr. <derbyw@derbtronics.com> wrote:
On 11 Jan 2001 16:15:16 GMT, Norbert Black <> nblack@qnx.com> > wrote:
I know this is a typo, but I have this bizarre vision of you
competing in the “Iron Chef” competition, software category… >Bill’s choice of a while loop is suprising but I don’t think it works
in the program. Yes - it’s too spicy for my tastes…But the Iron Chefs use of conditional statements
is very good…yes…I really like this…The Iron Chef wins again…
Souldn’t be? Here’s a bit of sample code that emits a raw key
event directly at the device region:Just what the doctor ordered… The completed filtering example
is at ftp.derbtronics.com as remote.c and remote.read. It now does
everything it’s supposed to.
Great. I’ll grab a copy as soon as I get a moment. Thanks a lot
for slogging away in the trenchs on this one.
Is there any chance I can get these or some other flag bits reserverd?
(as USER flag bit or some such thing?)
You could always ask – best way to start the ball rolling
formally is to make a request via the QDN website for a feature
enhancement. It strikes me as a plausible request, at least. I
recommend going in via the web site so that there’s some sort of
formal “a customer really did request this” papertrail.
If you do put this on QDN please also put it up as a region example –
That’s where it would make sense for it to go, I’d think.
There is a real darth of information/examples on doing stuff at this
level.
This one is strong in the ways of the force…
Might I be allowed a commercial?
I’ve spent most of the last 3 months writing an advanced Photon
programming course that covers region level stuff (among other
things) in some considerable detail. The previous Photon 1.1x
course was pretty good on a lot of this material, but the Advance
course (which assumes you’ve had a chance to do the tutorials and
a bit of tinkering besides) has a chance to spend real time on
some of the meatier issues. The “Regions” and “From Regions to
Widgets” chapters are both very close to 100 pages long, for
instance. The first edition of the course is late next month, and
the QNX website has further details on time/contents/etc.
We’ve had a lot of requests for this sort of course, and the
Training group has allocated a not-insubstantial amount of time
and treasure trying to make it a reality. It would be nice to
see a steady flow of students…
Oh, and by the way, I agree that it would be ideal for the online
docs to be able to give everyone what they need, but honest and
for true, I found 80% or more of the course material is available
in the current version of the RTP docs available inhouse here
(coming to a mythical patch near you! ), and most of the rest
was the result of persistant tinkering with code samples.
My advantage, of course, was that I’ve taken/taught/upgraded our
Photon course (now courses) for almost two years now, so I’ve got
a fair idea of how things hang together, even if I have to go
digging for syntax and details on a lot of occasions.
So, how about it folks? Anyone want to keep me busy in the
classroom?
Thus endeth the commercial.
Norbert Black
QSSL Training Services
On 11 Jan 2001 23:42:46 GMT, Norbert Black <nblack@qnx.com> wrote:
Is there any chance I can get these or some other flag bits reserverd?
(as USER flag bit or some such thing?)You could always ask – best way to start the ball rolling
formally is to make a request via the QDN website for a feature
enhancement. It strikes me as a plausible request, at least. I
recommend going in via the web site so that there’s some sort of
formal “a customer really did request this” papertrail.
Uhh, okay and where exactly would one make such a request?
Problem Reporting?
Site Comments?
Product Feedback?
qdn.public.articles?
If you do put this on QDN please also put it up as a region example –
That’s where it would make sense for it to go, I’d think.
There is a real darth of information/examples on doing stuff at this
level.heavy breathing> This one is strong in the ways of the force…
Might I be allowed a commercial?
I’ve spent most of the last 3 months writing an advanced Photon
programming course that covers region level stuff (among other
things) in some considerable detail. The previous Photon 1.1x
course was pretty good on a lot of this material, but the Advance
course (which assumes you’ve had a chance to do the tutorials and
a bit of tinkering besides) has a chance to spend real time on
some of the meatier issues. The “Regions” and “From Regions to
Widgets” chapters are both very close to 100 pages long, for
instance. The first edition of the course is late next month, and
the QNX website has further details on time/contents/etc.We’ve had a lot of requests for this sort of course, and the
Training group has allocated a not-insubstantial amount of time
and treasure trying to make it a reality. It would be nice to
see a steady flow of students… >Oh, and by the way, I agree that it would be ideal for the online
docs to be able to give everyone what they need, but honest and
for true, I found 80% or more of the course material is available
in the current version of the RTP docs available inhouse here
(coming to a mythical patch near you! >
was the result of persistant tinkering with code samples.My advantage, of course, was that I’ve taken/taught/upgraded our
Photon course (now courses) for almost two years now, so I’ve got
a fair idea of how things hang together, even if I have to go
digging for syntax and details on a lot of occasions.So, how about it folks? Anyone want to keep me busy in the
classroom? >Thus endeth the commercial.
A fine commercial indeed - though at this point I think there is only
two of us in the room.
Actually the online Docs are usually pretty good - certainly much
better than they were in '96 when I started this stuff… But in
general manuals are good for reminding you of detail on something
already know or guessed. i.e. You knew enough to look up the
function. Code samples show you how everything “hangs
together” as you say and leads you to related functions.
I would be a happy man if EVERY item in the manual referenced an
example showing its use. In the photon stuff in
particular if the widget reference showed an example of
setting/getting the main attribute of the widget it would certainly
help – It does tell you the attributes – which then forces you to
look the type of the attribute and wade around until you can determine
how you set/clear/load that attribute. In every widget (phab) type
program I do - I ALWAYS end up generating a bunch of wrapper
function for doing this i.e. SetText for a label or SetOnOff for a
button widget - because I find the Set/GetArg thing clumsy and
non-intuitive – i.e. Oh yeah to set the state of something I need to
set a local variable and then pass a pointer in the arg list or is
that a local pointer and then pass the address of THAT…
I know there are now helper functions for some of this now but it
took 4 years to get this far and there still isn’t a standard set (as
far as I know)
It always seemed strange to me that a set of standard wrapper was
not developed from day one… Am I really the only one who made his own
wrappers over and over again?? As for readability the whole Arg thing
is teriible. Lets see, 3 lines of code to change anything – of course
if your changing lots of stuff on a single widget this ratio gets
better – But in my application code most of my stuff involves
changing 1 attribute on a bunch of different widgets. With say 10
widgets you end up with 30+ lines in sets of 3 lines each which all
basically look the same - over and over - with small changes in each
set… (Fist raised defiently in the air) Why?? - Why?? - Why??
(lightning cracks)
Railing against the gods is a fine Hobby and a pleasant distraction.
Just my $ 0.02
Suddenly the red mist clears…
Of course I never was able to attend any of the classes for both
financial and time reasons. (“You’re the software expert - why would
you need to take a class?”) Pity that… 
Thanks again for the help on this problem. The rant above is in no way
aimed in your direction.
–Bill
William M. Derby Jr. <derbyw@derbtronics.com> wrote:
On 11 Jan 2001 23:42:46 GMT, Norbert Black <> nblack@qnx.com> > wrote:
snip
Is there any chance I can get these or some other flag bits reserverd?
(as USER flag bit or some such thing?)You could always ask – best way to start the ball rolling
formally is to make a request via the QDN website for a feature
enhancement. It strikes me as a plausible request, at least. I
recommend going in via the web site so that there’s some sort of
formal “a customer really did request this” papertrail.Uhh, okay and where exactly would one make such a request?
Problem Reporting?
Site Comments?
Product Feedback?
qdn.public.articles?
Ah, drat – I’d understood they’d made that relatively obvious.
sigh I believe the routine is to submit it in the same form
that’s used to report bugs (wherever that may be…
Hey you Tech Support folks – where the heck is it?
Norbert Black
QSSL Training Services
William M. Derby Jr. <derbyw@derbtronics.com> wrote:
On 11 Jan 2001 23:42:46 GMT, Norbert Black <> nblack@qnx.com> > wrote:
Might I be allowed a commercial?[snip]
Thus endeth the commercial.A fine commercial indeed - though at this point I think there is only
two of us in the room. >
I can clear a room in seconds…
Actually the online Docs are usually pretty good - certainly much
better than they were in '96 when I started this stuff… But in
general manuals are good for reminding you of detail on something
already know or guessed. i.e. You knew enough to look up the
function. Code samples show you how everything “hangs
together” as you say and leads you to related functions.I would be a happy man if EVERY item in the manual referenced an
example showing its use.
Really? A completely different point of view (and none the less
valid). The current layout seems completely natural to me.
shrug
Anyway, Steve Reid, who’s chained to the Photon documentation, is
a careful reader of this conference, so he may have some comments
or observations.
- i.e. Oh yeah to set the state of something I need to
set a local variable and then pass a pointer in the arg list or is
that a local pointer and then pass the address of THAT…
There is PtGetResource() which would do it all in one line.
PtSetResource() is the equivalent for setting.
It always seemed strange to me that a set of standard wrapper was
not developed from day one… Am I really the only one who made his own
wrappers over and over again??
What can I say? I may be brainwashed, but it all seems natural
to me.
(Fist raised defiently in the air) Why?? - Why?? - Why??
(lightning cracks)
Of course I never was able to attend any of the classes for both
financial and time reasons. (“You’re the software expert - why would
you need to take a class?”) Pity that… >
sigh Try selling them a substantially cut down development
cycle. We usually figure we can cut a month out of folk’s
development cycle (if they’re new to Photon) with the old 1.1x
course (or the Photon 2 intro course I’ll be teaching this
spring). Sometimes if you throw the figures involved in that at
the local pointy-haired boss, it helps.
Thanks again for the help on this problem. The rant above is in no way
aimed in your direction. >
No worries. I didn’t take it as such. Besides, constructive
venting is a good way to let the docs folk know about stuff, and
also to convince the R&D crowd that not everybody programs/thinks
the same way they do.
Oh, by the way, I grabbed a copy of your sample, and it seems to
perform as expected/described here on my RTP box. Once I get
this edition of the course put to bed at month’s end, I’ll review
it in fine detail and then shove it in the direction of the QDN
maintainers for posting on the site.
Thanks again, Bill.
Norbert Black
QSSL Training Services
On 12 Jan 2001 19:53:37 GMT, Norbert Black <nblack@qnx.com> wrote:
You could always ask – best way to start the ball rolling
formally is to make a request via the QDN website for a feature
enhancement. It strikes me as a plausible request, at least. I
recommend going in via the web site so that there’s some sort of
formal “a customer really did request this” papertrail.Uhh, okay and where exactly would one make such a request?
Ah, drat – I’d understood they’d made that relatively obvious.
sigh I believe the routine is to submit it in the same form
that’s used to report bugs (wherever that may be…Hey you Tech Support folks – where the heck is it? >
Well? I need the change for both QNX4 and NTO now - see below…
I would be a happy man if EVERY item in the manual referenced an
example showing its use.Really? A completely different point of view (and none the less
valid). The current layout seems completely natural to me.
shrug
?!?!? when is an example a bad idea? It’s not the manual layout -
thats fine - its just the widgets don’t have examples of their use so
I always have to guess or steal from a previous project.
BTW I’m not advocating the every word is a hyperlink thing - just an
example or snippet of the thing being used…
I don’t work on/create a phab/widget app every day - more like once a
month - so I forget each time… Call me slow I guess…
Anyway, Steve Reid, who’s chained to the Photon documentation, is
a careful reader of this conference, so he may have some comments
or observations.
I’m guessing that he’s too busy with the mythical patch A and
answering NTO questions. Or watching the latest Igor/Armin verbal
tennis match du jour. Actually Armin vs. anyone…
Oh, by the way, I grabbed a copy of your sample, and it seems to
perform as expected/described here on my RTP box. Once I get
this edition of the course put to bed at month’s end, I’ll review
it in fine detail and then shove it in the direction of the QDN
maintainers for posting on the site.
Actually if you grab it again you can get the dual NTO/QNX4 version
The Is_Relay had to be changed because there is no _psinfo in NTO
but it now compiles under both platforms (like most (all soon) of the
rest of my stuff -sigh)
-Bill
William M. Derby Jr. <derbyw@derbtronics.com> wrote:
: ?!?!? when is an example a bad idea? It’s not the manual layout -
: thats fine - its just the widgets don’t have examples of their use so
: I always have to guess or steal from a previous project.
It would be nice to have more examples. I’ll see what I can do.
:>
:>Anyway, Steve Reid, who’s chained to the Photon documentation, is
:>a careful reader of this conference, so he may have some comments
:>or observations.
: I’m guessing that he’s too busy with the mythical patch A and
: answering NTO questions. Or watching the latest Igor/Armin verbal
: tennis match du jour. Actually Armin vs. anyone…
Actually, I’ve been quietly following this thread; it has some good ideas
for the docs. (I’ve taken to ignoring the Igor/Armin tussle.)
Thanks for the suggestions.