VBX
4 messages in this thread
Dear Friend,
I am no longer concerned with the installation of the tool for vb.
What I am most concerned about is the flash of the background color that occurs
when closing or hiding the animation. Is there a way to avoid this situation.
I would like to be able to either load the last frame into the box that
contains the animator or get rid of the background box. Is there a workaround
for this situation. Also, is there a way to force the animator to conform to a
palette that I give it at run-time.
Thanx- Adlai
I have been going through this issue with several different people at the same
time, I'm not sure whether you have gotten the whole thread or not, so here is
everything on the subject.
There are two reasons that you will see palette flashes and have a lack of
control over your animation. First is the palette, and second is the way the
animation window is created.
1. Palette
FLC files do not conform to the Windows Palette standards, and they are not
controlable. Windows reserves (out of a palette of 256 colors) the first ten
and last ten palette positions for its own use. Thus, to avoid conflicts, your
animations must have a palette of 236 colors, avoiding using the fist ten and
last ten palette positions. Also, they should be a common palette for every
frame of the animations.
To reiterate:
A. You have a common pallete for every frame of the animation.
B. Your palette consists of 236 (not 256) colors.
C. Those 236 colors are in the center of the 256 color palette, leaving the
first ten and last ten palette positions empty so that Windows may utilize them
as it so desires. (Windows pre-empts the first ten and last ten positions from
the 256 palette.)
2. Animaton Window
Many of the Windows controls you would expect to be present, and expect to
apply to the Animation Window you create, can not be performed, thus control
of the animation window is very difficult. This is because the player window
is really two windows. First there is the child window, the one you create
from your application. Then there is a second borderless windows that is
carefully laid on top of the child, only its not a child window, its a parent
window of the AAPLAY.DLL. This is why it can't be controlled because it really
isn't owned by the application that is using the DLL.
I hope these two issues can help you get a grip on the problems you are having.
Hopefully you can work around the constraints that they provide. If I didn't
address your question, or this is all old information to you, let me know.
-Brian
Thank you for the response on this subject. I'll close my comments with one
last wish item. If there were a way that we could provide the animator with a
memory device context to communicate with, rather than a pair of windows, we
could have ultimate control in those instances where it would be necessary.
Short of that, maybe we could setup memory space for a DIB and allow us to do
what we wish with the palette.
In any event, when showing off my app, the animation always get's the wows.
I'm glad there's still a little gee-wiz out there:>
Rich,
Thanks for the wishlist items. These have been asked about before, but I will
forward it along as yet another vote for certain features.
-Brian