Forum unknown
· Programming
#MyWindow on YourScreen
15 messages in this thread
cheath,
I suppose one could just re-direct the CloseScreen() function and
intercept it for the current screen, and close the window before allowing it
to proceed. Wouldn't that be easier? —Mike
Easier, yes, but also more likely to run into problems both in the short and
particularly in the long run. For me, for a commercial thing, I'd rather go
for a way to share screens that is "guaranteed" to work among cooperating
applications. Wish C= would take the lead…
…cheath
Cheath,
The only way to guarantee it would be to insist that everyone do it. It's
just like the resource library; one is 'supposed' to use it, but even CBM
doesn't (in some cases). —Mike
Nak, having a shared screen library would make it safe for any applications
which register a shared screen. 100%, guaranteed safe. You would be limited
to programs which use the library, but for those programs you're golden,
rather than worrying about whether the program whose CUSTOMSCREEN you are
visiting is going to puke under some obscure conditions. I prefer running
closed-loop when possible, this is a case where it is possible-
…cheath
Cheath,
As long as the source for that library is available, I'm all for it!
—Mike
Why do you want the source for the library public? I'd never use calls to
a library with PD source, because you'd never know what the functions you
call would be doing with the myriad different versions of the library that
would be floating around. It would be nice to have a printed listing of
tricky sections for documentation, but not for allowing different versions
of the library to be built- …cheath
cheath,
Since one could SetFunc the library anyway, why the worry? If someone
wanted to be nasty, they could still supply their own library.
My beef is that for any particular application, there are always faster
and smaller ways of doing something than what is in a general purpose
library. Just look at FastFonts! 8) ] If I knew what was in a library
routine, when I do a SetFunc(), I could then be CERTAIN that I am not doing
something 'wrong'. But using SetFunc's is (among many other shortcomings)
wasteful of memory (and speed), whereas re-writing the library is more
efficient (and not using the library is faster, although less space efficient
for multiple tasks).
My interest happens to be i'facing to the outside world, and in many cases
(as I'm sure you know), it's not a matter of "Let's make it as fast as we
can", but "if it's not fast enuf, it won't work". As it happens, there are
some things the Amiga can't do and the Apple II can (primarily due to the
text display on the Apple II), even considering the 're-writing' of a library
by fast Fonts.
BTW, I never have figured out why FastFonts (and FF-clones) screws up the
display on this one program I have with 4 bitplanes, but I went to 3 planes
for other reasons anyway. Perhaps if I knew exactly what Text() does, I
could figure it out. (but then, maybe not). —Mike
Love these religious issues. Even if you've got source code for a library,
the implementation should be able to change completely except for the
functional spec – thus depending on the implementation can get you into
trouble when the implementation changes down the road with new hardware or
rearranged software.
Sure folks can setfunction you and blow a library function out of the water
just as easily as if the library itself was broken … that's why I don't
like to use Setfunction. 'Nuff said by me, let's go out drinking-
Love these religious issues. Even if you've got source code for a library,
the implementation should be able to change completely except for the
functional spec – thus depending on the implementation can get you into
trouble when the implementation changes down the road with new hardware or
rearranged software.
Sure folks can setfunction you and blow a library function out of the water
just as easily as if the library itself was broken … that's why I don't
like to use Setfunction. 'Nuff said by me, let's go out drinking-
cheath,
Since one could SetFunc the library anyway, why the worry? If someone
wanted to be nasty, they could still supply their own library.
My beef is that for any particular application, there are always faster
and smaller ways of doing something than what is in a general purpose
library. Just look at FastFonts! 8) ] If I knew what was in a library
routine, when I do a SetFunc(), I could then be CERTAIN that I am not doing
something 'wrong'. But using SetFunc's is (among many other shortcomings)
wasteful of memory (and speed), whereas re-writing the library is more
efficient (and not using the library is faster, although less space efficient
for multiple tasks).
My interest happens to be i'facing to the outside world, and in many cases
(as I'm sure you know), it's not a matter of "Let's make it as fast as we
can", but "if it's not fast enuf, it won't work". As it happens, there are
some things the Amiga can't do and the Apple II can (primarily due to the
text display on the Apple II), even considering the 're-writing' of a library
by fast Fonts.
BTW, I never have figured out why FastFonts (and FF-clones) screws up the
display on this one program I have with 4 bitplanes, but I went to 3 planes
for other reasons anyway. Perhaps if I knew exactly what Text() does, I
could figure it out. (but then, maybe not). —Mike
Why do you want the source for the library public? I'd never use calls to
a library with PD source, because you'd never know what the functions you
call would be doing with the myriad different versions of the library that
would be floating around. It would be nice to have a printed listing of
tricky sections for documentation, but not for allowing different versions
of the library to be built- …cheath
Cheath,
As long as the source for that library is available, I'm all for it!
—Mike
Nak, having a shared screen library would make it safe for any applications
which register a shared screen. 100%, guaranteed safe. You would be limited
to programs which use the library, but for those programs you're golden,
rather than worrying about whether the program whose CUSTOMSCREEN you are
visiting is going to puke under some obscure conditions. I prefer running
closed-loop when possible, this is a case where it is possible-
…cheath
Cheath,
The only way to guarantee it would be to insist that everyone do it. It's
just like the resource library; one is 'supposed' to use it, but even CBM
doesn't (in some cases). —Mike
Easier, yes, but also more likely to run into problems both in the short and
particularly in the long run. For me, for a commercial thing, I'd rather go
for a way to share screens that is "guaranteed" to work among cooperating
applications. Wish C= would take the lead…
…cheath