on 1/23/05 12:51 AM, Einhugur Software at bjorn at einhugur dot com wrote:
> BackColors have worked for me (up to a point)
>
> That is if you call a REALbasic Graphics call (any such, even setting
> the Graphics) then the back color gets lost.
Oh no!, and I am using graphics calls. I figured that by setting the
window.hasbackcolor allows for the backcolor change of the control, but only
on a non-composite window. Currently, I don't have any background color at
all, while the lib expects a background color. darn, using dynamic access to
a graphics object, in addition to two sliders, and a canvas seemed to be so
cool... So this statement from you supports my evolving notion that the
plugin becomes more and more dependent on RB's performance and potential
bugs. I am not really satisfied:
For example, when a non-metal window is chosen but with composite flag and
hasbackcolor = false, clicking in one of the arrow areas of the slider,
shows a white background, but when dragging the thumb this white background
disappears.
I wonder what else I can expect with the approach I have chosen. Going back
to a plugin model not based on dynamic access will be a huge task, while the
conclusion of dynamic access, using existing controls, appears very
disappointing....
Alfred
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|