Hi Sarah,
Formattedheight and -width don't work correctly if the player is
hidden or
if a stack is being opened and the players is being loaded before
the stack
window is visible.
Not a problem for my app.
There are problems with visual effects.
Again, not a problem for my app.
There
On Oct 9, 2009, Sarah wrote:
So if using players is such a bad idea, what else?
Well, this is a little crazy but inexplicable limitations can make one
crazy.
How about vertically slicing images greater than 4000 pixels, then
throwing the resulting sub-images into a group?
For
Good idea, but the problem is that as soon as the engine deals with
the image at all, the imagedata is corrupt. See bug #4026
http://quality.runrev.com/qacenter/show_bug.cgi?id=4026
--Jerry Jensen
On Oct 9, 2009, at 10:26 AM, Jim Lambert wrote:
On Oct 9, 2009, Sarah wrote:
So if using
Bug 7290 may affect you. It makes the player useless for me (I need
to dynamically set the window title).
http://quality.runrev.com/qacenter/show_bug.cgi?id=7290
Unlike the report's main description, the issue is not just associated
with unlocking the screen.
It would be really nice if someone
As has been discussed before, there is a problem with image objects on
OS X if the image they are trying to display is wider than about 4000
pixels.
BUT a player object will display these wide images without any problems.
So is there anything I should know before I change to using players
instead
Hi Sarah,
Formattedheight and -width don't work correctly if the player is
hidden or if a stack is being opened and the players is being loaded
before the stack window is visible.
There are problems with visual effects.
There are lots of problems with putting objects over player objects.
Formattedheight and -width don't work correctly if the player is hidden or
if a stack is being opened and the players is being loaded before the stack
window is visible.
Not a problem for my app.
There are problems with visual effects.
Again, not a problem for my app.
There are lots of
