From: Dan Johnston (dan.johnston++at++nrc.ca)
Date: 09/05/2003 05:23:43
Jason Daly wrote:
> On Thu, 2003-09-04 at 15:02, Alexandre Naaman wrote:
> >
> > The reason that this sample is commented out from the Makefile on win32
> > is because it uses X input in lieu of pfutil's input mechanism. This isn't
> > the only sample which hasn't been fully ported (there are many lib
> > src/pguide/libpf) but most of those that aren't ported fall into this
> > category as well.
>
> Alexandre (and others),
>
> Along these lines, I tried to take some code that was using plain old
> Win32 input and port it to use Performer. Essentially, I open a
> pfPipeWindow, then subclass the WNDCLASS (using SetWindowLong) to
> install my own main window procedure. When I do this, I get all the
> keyboard events I'm looking for, but I don't get any mouse events. Is
> this because pfUtil is skimming all the mouse events before I get them?
> If so, is there any way around this? I'd like to avoid switching to
> pfUtil if possible because I want the code to stay portable.
>
> Thanks in advance.
>
> --"J"
>
Yes. I also understand your problem. The reason I was creating a test
program to display simple text messages as 3D models, was because
I was working on adding some 'standard' socket streams to the
normal pfUtil input streams. I had this working on IRIX and Linux
for a VR library I created (Alexandre knows of my pfAPC library
and its features). Now I have socket streams working on MS-Windows.
I could not think of any other way, so I have a Visual Studio workspace
which takes a modified version of input.c (from SGI's pfUtil) and adds
some extra features - including a few predefined socket streams -
and then compiles this code and all the other functions in the pfUtil
and pfUi library directories. The resulting DLL is used instead
of the SGI DLL to provide the extra functionality to all my applications.
Why do all this? Because input.c contains static data structures and
statuc functions which are only visable within the source file. Functions
within the input.c source which need to be public (for your application
to call) also make use of these static functions and data, so they must
also be defined in the input.c source file. Now if you want to add code
to a copy of this source file - as I have done - and want
your application to use the new functions, you need only link to the
modified objects. But all the pfXXX functions in the SGI DLLs will
use the input.c code in the SGI pfUtil DLL instead. You have to
make sure that all the pfUtil DLL is replaced with one that
provides all the other functionality and a modified version of the
input.c code. It took me a day and a half to get the new DLL compiled
and my applications to use it instead of the SGI DLL.
Because I am very new to WIN32 programming, I ended up creating
my own pseudo-window (never realized) and assigned the existing
window procedure found in input.c as the event-handling procedure
for my pseudo-window. I did not know how to get all the existing
window 'handles' for the performer display. With what I now know,
and the hint from Alexandre, I could probably eliminate this extra
pseudo window - but it does work fine as-is!
I hope that my comments and suggestions (above) were also of
some help.
Dan Johnston
--
___|__ |
/ | \ ||\ Daniel (Dan) Johnston
/___|___\ || \ Dan.Johnston++at++nrc.gc.ca
_____|____ || \ National Research Council of Canada, London, ON
| | | || \ Integrated Manufacturing Technologies Institute
\___| | | ||____\ Tel: (519) 430-7081 Fax: (519) 430-7090
\_o_\___|____|_|______\_ Inst: http://www.nrc.gc.ca/imti
\ o / These opinions are my own! Not those of NRC.
\________________/ Virtual Reality:
http://www.nrc.ca/imti/vetc/home.html
More Tall Ships - Fewer Computers!
This archive was generated by hypermail 2b29 : Fri Sep 05 2003 - 05:26:30 PDT