CompuServe Thread

VBX

4 messages in this thread
#98674From: SteveApr 25, 1994 5:00 PM
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
#98746From: Brian Rudolph [Adesk]Apr 26, 1994 10:15 AM
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
#100013From: Rich FrankMay 4, 1994 9:45 PM
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:>
#100112From: Brian Rudolph [Adesk]May 5, 1994 10:36 AM
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