plib-devel

[Plib-devel] TO-DO Update

[tjones <tj...@is...>]

Hello

Is there a location for a TODO list. I would like to build a list of =
features that would like to be added (and how important they are) and =
what has be fix or cleaned up (and of course how important).

Ben Woodhead

Re: [Plib-devel] PLIB developers needed.

[Steve B. <sjb...@ai...>]

Gil Carter wrote:
 
>> But I doubt that we can run the famous Mont Blanc demo from SGI where
>> you can zoom from a space view of the earth down to the Mont Blanc and
>> fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
>> me that the textures had a resolution of 1 metre and you could see the
>> walking tracks...
> 
> IIRC, that application is also a pretty good demonstration of Performer's
> ClipTextures, which allow the management of much larger textures than will
> fit into physical texture memory.  I think ClipTextures are implemented
> using special hardware on the Onyxes, so that demo will need some major
> surgery to work on a PC!

It certainly does use clip-texture - that's why they wrote that particular
demo.

However, it's a rather 'rigged' demo because you can only zoom in on
Mont Blanc - you can't (for example) zoom in on a point 10 miles south
of there.

They had a version where you zoomed in past the mountain and onto a
Nintendo-64 (which was developed by SGI) - through the case and down
into the 'Reality Chip'.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] PLIB developers needed.

[Gil C. <g.c...@ca...>]

>
>But I doubt that we can run the famous Mont Blanc demo from SGI where
>you can zoom from a space view of the earth down to the Mont Blanc and
>fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
>me that the textures had a resolution of 1 metre and you could see the
>walking tracks...

IIRC, that application is also a pretty good demonstration of Performer's 
ClipTextures, which allow the management of much larger textures than will 
fit into physical texture memory.  I think ClipTextures are implemented 
using special hardware on the Onyxes, so that demo will need some major 
surgery to work on a PC!

Gil

RE: [Plib-devel] Rendering really, really large displays

[Vallevand, M. K <Mar...@UN...>]

I played with this a while ago trying to go exactly that - hires
screen snaps.  I had mixed results, and gave up.

In theory, it should work.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.


> -----Original Message-----
> From: Curtis L. Olson [mailto:cu...@me...]
> Sent: Wednesday, August 16, 2000 3:30 PM
> To: pli...@li...
> Subject: [Plib-devel] Rendering really, really large displays
> 
> 
> I just ran across Brian Paul's little utility library that renders a
> series of tiles to achieve potentially huge pixel resolution displays.
> This is good for screen snapshots, not real time rendering ...
> 
>     http://www.mesa3d.org/brianp/TR.html
> 
> This library requires a call to trFrustum() which is analogous to
> glFrustum().
> 
> Ok, so now is as good a time as any to admit that after many years of
> ssg use, Steve's master plan is now complete -- my mind is complete
> mush.  I've forgotten the intricacies of setting the modelview matrix
> vs. the project matrix and all that fun stuff.  I've even forgotten if
> I ever really understood them in the first place.
> 
> So the question is, has anyone played around with using this library
> in an ssg application?  If I wanted to forge ahead, could I just do
> something like the following:
> 
>     ssgContext *mycontext = ssgGetCurrentContext();
>     sgFrustum *myfrustum = mycontext->getFrustum();
> 
>     /* A */
> 
>     trFrustum( myfrustum->getLeft(), myfrustum->getRight(),
>                myfrustum->getTop(), myfrustum->getBot(),
>                myfrustum->getNear(), myfrustum->getFar() );
> 
>     // proceed with the "TR" lib code to render out all the subtiles
> 
> Does this sound reasonable or do I need to do additional magic at
> point /* A */ in the above code to get the projection matrix setup
> correctly?
> 
> In the ssg.h file, ssgGetCurrentContext() is in a "backwards
> compatibility" section.  Is there a better way now to get the current
> Frustum matrix?
> 
> Any thoughts before I go off to waste 2 weeks of my time trying to
> figure all of this out?
> 
> Thanks,
> 
> Curt.
> -- 
> Curtis Olson   Human Factors Research Lab       Flight Gear Project
> Twin Cities    cu...@hf...                cu...@fl...
> Minnesota      http://www.menet.umn.edu/~curt   
> http://www.flightgear.org
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] Rendering really, really large displays

[Curtis L. O. <cu...@me...>]

I just ran across Brian Paul's little utility library that renders a
series of tiles to achieve potentially huge pixel resolution displays.
This is good for screen snapshots, not real time rendering ...

    http://www.mesa3d.org/brianp/TR.html

This library requires a call to trFrustum() which is analogous to
glFrustum().

Ok, so now is as good a time as any to admit that after many years of
ssg use, Steve's master plan is now complete -- my mind is complete
mush.  I've forgotten the intricacies of setting the modelview matrix
vs. the project matrix and all that fun stuff.  I've even forgotten if
I ever really understood them in the first place.

So the question is, has anyone played around with using this library
in an ssg application?  If I wanted to forge ahead, could I just do
something like the following:

    ssgContext *mycontext = ssgGetCurrentContext();
    sgFrustum *myfrustum = mycontext->getFrustum();

    /* A */

    trFrustum( myfrustum->getLeft(), myfrustum->getRight(),
               myfrustum->getTop(), myfrustum->getBot(),
               myfrustum->getNear(), myfrustum->getFar() );

    // proceed with the "TR" lib code to render out all the subtiles

Does this sound reasonable or do I need to do additional magic at
point /* A */ in the above code to get the projection matrix setup
correctly?

In the ssg.h file, ssgGetCurrentContext() is in a "backwards
compatibility" section.  Is there a better way now to get the current
Frustum matrix?

Any thoughts before I go off to waste 2 weeks of my time trying to
figure all of this out?

Thanks,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] SSG bux fixes for untextured .3ds objects

[Ben W. <be...@bg...>]

Did anybody resolve this issue yet.

I will take a look at it if you would like.

Dan if you can send me your code and the model you are having problems with,
I will see what  I can do.

Later Ben

-----Original Message-----
From: Dan Gelb [mailto:dg...@hp...]
Sent: Monday, August 14, 2000 2:32 PM
To: pli...@li...
Subject: [Plib-devel] SSG bux fixes for untextured .3ds objects


Last week I posted on plib-users about problems I was having with .3ds
objects
that were not textured.  I figured out a couple changes that solved the
problems
for me, and I'm assuming this is the right place to post them.

1. Non-textured objects show up as white when textured objects drawn before
them.

I started with the tux ssg example program.  One of the textured objects
drawn
sets the GL_EMISSION material values to 1.0,1.0,1.0.  When the .3ds objects
are
drawn without textures it sets the ambient, diffuse, and specular material
properties,
but doesn't set the emissive back to 0.0.  I added a line to
ssgSimpleState::apply
to set it to 0.0 if it isn't specified.  I don't know if this is the correct
place or
not.

2. First non-textured object always shows up as white in scene with or
without textures

I believe this was happening because glDisable(GL_COLOR_MATERIAL) is called
AFTER
the glMaterial calls in ssgSimpleState::apply.  This causes the glMaterial
calls
to be ignored for the first object, but work for subsequent objects.  I
think that is
what happens.  My workaround was to move the ssgDisableTable call to before
the glMaterial calls.

I don't know if either of these is the proper solution, or if they would
break
other areas.  They seemed to work for me though.

Dan

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] TCP code for ulnet

[Ben W. <be...@bg...>]

Thanks alot Norman, that worked.

Here is the fixed code. 

Later Ben

There are still some nasty code in there, if possible can someone fix it up
and post it.


-----Original Message-----
From: Norman Vine [mailto:nh...@ca...]
Sent: Wednesday, August 16, 2000 11:55 AM
To: pli...@li...
Subject: RE: [Plib-devel] TCP code for ulnet


Ben Woodhead writes:
>
>The problem is to work with a TCP connection I need the function connect
>from one of the network headers. And everytime I try to compile it tries to
>use connect from this class, is there anyway around that.

::connect( sockfd, (struct sockaddr *) out_addr, sizeof(sockaddr_in))

notice the scope operator ::

Norman


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] TCP code for ulnet

[Norman V. <nh...@ca...>]

Ben Woodhead writes:
>
>The problem is to work with a TCP connection I need the function connect
>from one of the network headers. And everytime I try to compile it tries to
>use connect from this class, is there anyway around that.

::connect( sockfd, (struct sockaddr *) out_addr, sizeof(sockaddr_in))

notice the scope operator ::

Norman

[Plib-devel] TCP code for ulnet

[Ben W. <be...@bg...>]

Hello 

I have been working on the TCP code for ulNet and I have almost complete
(except for bugs and code modification for portabiltiy and cleaness). But I
have a problem with name space in ulNet.cxx, the problem is that I have a
class
ulTCPConnnection
and a method
	ulTCPConnection::connect(**)

The problem is to work with a TCP connection I need the function connect
from one of the network headers. And everytime I try to compile it tries to
use connect from this class, is there anyway around that.

Thank Ben
ps Please let me know if the code is not attached.

RE: [Plib-devel] puSlider

[Dave M. <Dav...@dy...>]

Steve wrote:
> Personally, I wouldn't have overloaded the constructor at all.
> 
> I'd probably have done this:
> 
>    puSlider ( int minx, int miny, int sz,
>		int vertical = FALSE, int width = -1 )
>
> ...and then had this constructor simply treat width==-1
> to mean "whatever height fits the text"...or whatever
> it means now.
>

i agree that the 4th argument should always be 'vertical' but with only one
constructor, you need two nested conditional expressions to pass the right
values to puObject.  i changed

  puSlider ( int minx, int miny, int sz, int vertical = FALSE )
  puSlider ( int minx, int miny, int sz, int width, int vertical )

into

  puSlider ( int minx, int miny, int sz, int vertical = FALSE )
  puSlider ( int minx, int miny, int sz, int vertical, int width )

and commited that.  it's effectively the same as what you suggested Steve.

--Dave

RE: [Plib-devel] puSlider

[Fay J. F C. AAC/W. <joh...@eg...>]

You have to specify the "vertical=FALSE" when you want to specify the width,
even with the overloaded constructors.  Steve is right, one constructor
would be sufficient in that regard.  Handling the "width=-1" option will
take a bit of coding in the call to the "puObject" constructor but is
certainly feasible.

I agree that neither of the other two options I presented is optimal.  I
just wanted to make sure we had considered all the alternatives.

John F. Fay
joh...@eg...


-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Tuesday, August 15, 2000 16:56
To: pli...@li...
Subject: Re: [Plib-devel] puSlider


Personally, I wouldn't have overloaded the constructor at all.

I'd probably have done this:

   puSlider ( int minx, int miny, int sz, int vertical = FALSE, int width =
-1 )
 
...and then had this constructor simply treat width==-1 to mean "whatever
height fits the text"...or whatever it means now.

That forces you to say that you want a horizontal slider if you also want to
set the width - but that doesn't seem too much of a chore to me.

> Another way to fix this ... <snip>

Hmm - I don't like any of those things.
 

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] puSlider

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:
> 
> The problem Dave found was that there is an ambiguity between the original
> puSlider constructor with "vertical" specified and the new puSlider
> constructor with "vertical" left as a default.  If the user creates a new
> puSlider object with four integer arguments, the compiler doesn't know which
> constructor to call.

Personally, I wouldn't have overloaded the constructor at all.

I'd probably have done this:

   puSlider ( int minx, int miny, int sz, int vertical = FALSE, int width = -1 )
 
...and then had this constructor simply treat width==-1 to mean "whatever
height fits the text"...or whatever it means now.

That forces you to say that you want a horizontal slider if you also want to
set the width - but that doesn't seem too much of a chore to me.

> Another way to fix this might be to change the type of the variable
> "vertical".  It only takes the values TRUE and FALSE, so making it "short"
> should work.  Unfortunately, this could create confusion if the user creates
> a puSlider with four integer numbers:  the computer would know exactly which
> constructor it is calling, but the user wouldn't be able to tell easily
> without an explicit type casting.  A second alternative would be to make it
> "bool", but nothing else in PUI is "bool" and I don't know how portable it
> is.

Hmm - I don't like any of those things.
 

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] VRML Loader issues

[Dave M. <Dav...@dy...>]

not sure if blender VRML 1.0 export includes textures.  i exported *.blend
from tutor_1.02 and tutor_1.6 and none of the resulting .wrl files had any
texture coordinates or references to texture mapping.  perhaps none of the
tutor files are textured or i just missed an option there.  any blender
experts?

--Dave

>  But if Blender has VRML 1.0 export, that's the way to go,
> because it means there's a free, mature modeller available
> for plib. (1.0 is also easier to parse and load)
> 
> -cks

Re: [Plib-devel] VRML Loader issues

[Christopher K. S. J. <cs...@qu...>]

Chris Purnell wrote:
> 
> On Fri, Aug 11, 2000 at 03:45:22AM -0500, Steve Baker wrote:
> 
> This is not what I've found. 
>

 But if Blender has VRML 1.0 export, that's the way to go,
because it means there's a free, mature modeller available
for plib. (1.0 is also easier to parse and load)

-cks

RE: [Plib-devel] RE: puSlider

[Dave M. <Dav...@dy...>]

the width and height are not passed so you can't judge that.
or do i mis-understand?
 
puSlider ( int minx, int miny, int sz, int vertical = FALSE )
puSlider ( int minx, int miny, int sz, int width, int vertical )
 
--Dave


Hello 
 
Why don't you judge if its vertical or horizontal based on the size, in the
original constuctor.
 
Later Ben

[Plib-devel] RE: puSlider

[tjones <tj...@is...>]

Hello=20

Why don't you judge if its vertical or horizontal based on the size, in =
the original constuctor.

Later Ben

RE: [Plib-devel] puSlider

[Fay J. F C. AAC/W. <joh...@eg...>]

The problem Dave found was that there is an ambiguity between the original
puSlider constructor with "vertical" specified and the new puSlider
constructor with "vertical" left as a default.  If the user creates a new
puSlider object with four integer arguments, the compiler doesn't know which
constructor to call.
 
Another way to fix this might be to change the type of the variable
"vertical".  It only takes the values TRUE and FALSE, so making it "short"
should work.  Unfortunately, this could create confusion if the user creates
a puSlider with four integer numbers:  the computer would know exactly which
constructor it is calling, but the user wouldn't be able to tell easily
without an explicit type casting.  A second alternative would be to make it
"bool", but nothing else in PUI is "bool" and I don't know how portable it
is.
 

John F. Fay 
joh...@eg... 

 
-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Monday, August 14, 2000 18:53
To: 'pli...@li...'
Subject: RE: [Plib-devel] puSlider



Blake Friesen wrote: 
> I would like to be able to use a puSlider that I can set the 
> width (for horizontal slider) or the height (for a vertical 
> slider.)  Right now, the slider height is set according to 
> the height/width of the current font. 

Thanks Blake! 

I got an "ambiguous constructor error" on MSVC so I removed the default
parameter to make it work 

  puSlider ( int minx, int miny, int sz, int vertical = FALSE ) 
  puSlider ( int minx, int miny, int sz, int width, int vertical ) 

Let me know if that is a problem. 

--Dave 

RE: [Plib-devel] puSlider

[Dave M. <Dav...@dy...>]

Blake Friesen wrote:
> I would like to be able to use a puSlider that I can set the 
> width (for horizontal slider) or the height (for a vertical
> slider.)  Right now, the slider height is set according to
> the height/width of the current font.

Thanks Blake!

I got an "ambiguous constructor error" on MSVC so I removed the default
parameter to make it work

  puSlider ( int minx, int miny, int sz, int vertical = FALSE )
  puSlider ( int minx, int miny, int sz, int width, int vertical )

Let me know if that is a problem.

--Dave

[Plib-devel] puSlider

[Blake F. <umf...@cc...>]

I would like to be able to use a puSlider that I can set the width (for
horizontal slider) or the height (for a vertical slider.)  Right now,
the slider height is set according to the height/width of the current
font.  Here is a patch to pu.h that adds an alternate constructor that
allows this:

799a800,820
> 
> 
> /* start added by Blake Friesen */
>   puSlider ( int minx, int miny, int sz, int width, int vertical = FALSE
) :
>      puObject ( minx, miny, vertical ?
>                              ( minx + width ) :
>                              ( minx + sz ),
>                             vertical ?
>                              ( miny + sz ) :
>                              ( miny + width ) 
>                            )
>   {
>     type |= PUCLASS_SLIDER ;
>     slider_fraction = 0.1f ;
>     getValue ( & last_cb_value ) ;
>     vert = vertical ;
>     cb_delta = 0.1f ;
>     cb_mode = PUSLIDER_ALWAYS ;
>   }
> /* end added by Blake Friesen */
> 

RE: [Plib-devel] SSG bux fixes for untextured .3ds objects

[Dave M. <Dav...@dy...>]

Nice job tracking this down Dan!  I don't understand OpenGL lighting very
well so could another plib developer investigate this?

--Dave

> Last week I posted on plib-users about problems I was having 
> with .3ds objects
> that were not textured.  I figured out a couple changes that 
> solved the problems
> for me, and I'm assuming this is the right place to post them.
> 
> 1. Non-textured objects show up as white when textured 
> objects drawn before them.
> 
> I started with the tux ssg example program.  One of the 
> textured objects drawn
> sets the GL_EMISSION material values to 1.0,1.0,1.0.  When 
> the .3ds objects are
> drawn without textures it sets the ambient, diffuse, and 
> specular material properties,
> but doesn't set the emissive back to 0.0.  I added a line to 
> ssgSimpleState::apply
> to set it to 0.0 if it isn't specified.  I don't know if this 
> is the correct place or
> not.
> 
> 2. First non-textured object always shows up as white in 
> scene with or without textures
> 
> I believe this was happening because 
> glDisable(GL_COLOR_MATERIAL) is called AFTER
> the glMaterial calls in ssgSimpleState::apply.  This causes 
> the glMaterial calls
> to be ignored for the first object, but work for subsequent 
> objects.  I think that is
> what happens.  My workaround was to move the ssgDisableTable 
> call to before
> the glMaterial calls.
> 
> I don't know if either of these is the proper solution, or if 
> they would break
> other areas.  They seemed to work for me though.
> 
> Dan
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] OT: why no programmers for OpenSource games

[Dave M. <Dav...@dy...>]

In O'Reilly's "OpenSources: Voices from the Open Source Revolution", Brian
Behlendorf of Apache says:

p. 159
"""
Open-source software has tended to be slanted towards the
infrastructual/back-end side of the software spectrum represented here.
There are several reasons for this:

- End-user applications are hard to write, not only because a programmer has
to deal with a graphical, windowed environment which is constantly changing,
nonstandard, and buggy simply because of its complexity, but also because
most programmers are not good graphical interface designers, with notable
exceptions

- culturally, open-source software has been conducted in the networking code
and operating system space for years.

- open-source tends to thrive where incremental change is rewarded, and
historically that has meant back-end systems more than front-ends

- much open-source software was written by engineers to solve a task they
had to do while developing commercial software or services; so the primary
audience was, early on, other engineers.

This is why we see solid open-source offerings in the the operating system
and network services space, but very few offerings in the desktop
application space.
"""

For more info, buy the book, you'll enjoy it.  Especially, Larry Wall's
"free assocation" essay. :)

As a commercial game developer myself, I see plib and other open-source as a
better (more portable) alternative to DirectX for creating games.  I think
it is a win-win for everyone to help improve plib while competing at the
application level.

-- Dave McClurg
mailto:dav...@dy...         http://www.dynamix.com
mailto:da...@po... (home)            http://www.pond.net/~davem 

[Plib-devel] SSG bux fixes for untextured .3ds objects

[Dan G. <dg...@hp...>]

Last week I posted on plib-users about problems I was having with .3ds objects
that were not textured.  I figured out a couple changes that solved the problems
for me, and I'm assuming this is the right place to post them.

1. Non-textured objects show up as white when textured objects drawn before them.

I started with the tux ssg example program.  One of the textured objects drawn
sets the GL_EMISSION material values to 1.0,1.0,1.0.  When the .3ds objects are
drawn without textures it sets the ambient, diffuse, and specular material properties,
but doesn't set the emissive back to 0.0.  I added a line to ssgSimpleState::apply
to set it to 0.0 if it isn't specified.  I don't know if this is the correct place or
not.

2. First non-textured object always shows up as white in scene with or without textures

I believe this was happening because glDisable(GL_COLOR_MATERIAL) is called AFTER
the glMaterial calls in ssgSimpleState::apply.  This causes the glMaterial calls
to be ignored for the first object, but work for subsequent objects.  I think that is
what happens.  My workaround was to move the ssgDisableTable call to before
the glMaterial calls.

I don't know if either of these is the proper solution, or if they would break
other areas.  They seemed to work for me though.

Dan

RE: [Plib-devel] puDeleteObject

[Ben W. <be...@bg...>]

Sorry, replyed to the wrong message. What a day.

Later Ben

-----Original Message-----
From: Ben Woodhead 
Sent: Monday, August 14, 2000 11:14 AM
To: 'pli...@li...'
Subject: RE: [Plib-devel] puDeleteObject


Sure, it's being taken care of. 
Thanks Ben


-----Original Message-----
From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
Sent: Monday, August 14, 2000 10:27 AM
To: pli...@li...
Subject: RE: [Plib-devel] puDeleteObject


Thank you.  What I had submitted worked just fine for me, but I am glad that
you have made it more general.

John F. Fay
joh...@eg...


-----Original Message-----
From: Dave McClurg [mailto:dp...@ef...]
Sent: Sunday, August 13, 2000 01:13
To: pli...@li...
Subject: [Plib-devel] puDeleteObject


I fixed puDeleteObject so that it calls a smarter puPopLiveInterface.  This
allows a callback to delete the dialog it belongs to and create a new one.
This is important for chaining together interfaces (hit a button, delete the
old interface, create a new one).

See examples/src/pui/complex.cxx for an example.  hit File->Save and then
when you hit OK or CANCEL it brings up a little message dialog.

the changes have been commited to CVS.

--Dave


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] puDeleteObject

[Ben W. <be...@bg...>]

Sure, it's being taken care of. 
Thanks Ben


-----Original Message-----
From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
Sent: Monday, August 14, 2000 10:27 AM
To: pli...@li...
Subject: RE: [Plib-devel] puDeleteObject


Thank you.  What I had submitted worked just fine for me, but I am glad that
you have made it more general.

John F. Fay
joh...@eg...


-----Original Message-----
From: Dave McClurg [mailto:dp...@ef...]
Sent: Sunday, August 13, 2000 01:13
To: pli...@li...
Subject: [Plib-devel] puDeleteObject


I fixed puDeleteObject so that it calls a smarter puPopLiveInterface.  This
allows a callback to delete the dialog it belongs to and create a new one.
This is important for chaining together interfaces (hit a button, delete the
old interface, create a new one).

See examples/src/pui/complex.cxx for an example.  hit File->Save and then
when you hit OK or CANCEL it brings up a little message dialog.

the changes have been commited to CVS.

--Dave


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] puDeleteObject

[Fay J. F C. AAC/W. <joh...@eg...>]

Thank you.  What I had submitted worked just fine for me, but I am glad that
you have made it more general.

John F. Fay
joh...@eg...


-----Original Message-----
From: Dave McClurg [mailto:dp...@ef...]
Sent: Sunday, August 13, 2000 01:13
To: pli...@li...
Subject: [Plib-devel] puDeleteObject


I fixed puDeleteObject so that it calls a smarter puPopLiveInterface.  This
allows a callback to delete the dialog it belongs to and create a new one.
This is important for chaining together interfaces (hit a button, delete the
old interface, create a new one).

See examples/src/pui/complex.cxx for an example.  hit File->Save and then
when you hit OK or CANCEL it brings up a little message dialog.

the changes have been commited to CVS.

--Dave


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel