"Canvas does not allow drawing"
Lord Havelock Vetinari, the patrician
created some components now, and each and every one of them which draws
something, gives this error...
Rick Rogers (TeamB)
You are attempting to draw on a canvas before its handle has been allocated,
most likely by drawing in the constructor. Only draw in an overridden Paint
method and things should be fine.
- Rick
Rick Rogers (TeamB)
I'd be surprised if painting in an WM_NCPAINT message handler would cause
this problem, but perhaps it is true.
> Is there some way to find out if the handle was allocated yet
See the aptly named HandleAllocated function.
> Because I need to draw to a TWinControl derifate...
I'm not sure what the last word means.
- Rick
Rick Rogers (TeamB)
> to be draw at design time
No, not true, something else in your component is causing the error. See my
other message.
- Rick
Rick Rogers (TeamB)
This is a pretty confusing list to sort through, especially since a lot of
it may be unrelated to your problem, and also since you may be leaving out
critical details that are related to your problem. My suggestion: create a
small simplified component which does nothing but demonstrate the problem,
then post it here.
> Which handle should I check for: the one of the control (to see if it has
> been created)
I believe that it always safe to draw on a control's canvas when the
control's handle has been allocated, which is what HandleAllocated tells
you.
> How do you call it, when you expand the hyrarchy by one... ??
> I always tend to call it derifate, because it comes from "derive"
The English word you are thinking of is "derivative", but the common OOP
term is "descendant".
- Rick
Jeff Overcash (TeamB)
>
>
> Well, my component doesn't have a Paint or WM_PAINT handler, nor does it have
> a overridden constructor or destructor. It does have a CM_MOUSEENTER and
> CM_MOUSELEAVE handler, which inherite and then call Windows.SetFocus on the
> control itself.
> I also have a WM_SETFOCUS and WM_KILLFOCUS handlers, which do some stuff
> after being inherited and then call en WM_NCPAINT on the control.
>
A quick guess is that it is in the WM_SETFOCUS and WM_KILLFOCUS. Those get
called during creation time, but I do not think that the handle is created yet.
Put checks there to just exit and do nothing if there is no handle yet for the
control in each of those two methods and see if that fixes it. Check all
handles that you might be using.
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpetted corridors of Whitehall.
(Fish)
--
Lord Havelock Vetinari, the patrician
if the handle was allocated yet? Because I need to draw to a TWinControl
derifate...
Lord Havelock Vetinari, the patrician
> > Yeah, but what if I need to do it in a WM_NCPAINT?
>
> I'd be surprised if painting in an WM_NCPAINT message handler would cause
> this problem, but perhaps it is true.
>
Well, my component doesn't have a Paint or WM_PAINT handler, nor does it have
a overridden constructor or destructor. It does have a CM_MOUSEENTER and
CM_MOUSELEAVE handler, which inherite and then call Windows.SetFocus on the
control itself.
I also have a WM_SETFOCUS and WM_KILLFOCUS handlers, which do some stuff
after being inherited and then call en WM_NCPAINT on the control.
In the WM_NCPAINT I first get the device context and then use it to get a
TControlCanvas for the control. Here's where I draw some stuff and then I
release both the TControlCanvas and DC.
>
> > Is there some way to find out if the handle was allocated yet
>
> See the aptly named HandleAllocated function.
Which handle should I check for: the one of the control (to see if it has
been created) or the one of the TControlCanvas (which is actually the DC of
the control, but to check if it's accessible)...
>
>
> > Because I need to draw to a TWinControl derifate...
>
How do you call it, when you expand the hyrarchy by one... ?? I always tend
to call it derifate, because it comes from "derive", but maybe I'm wrong...
Please correct me if I am...
Lord Havelock Vetinari, the patrician
error happend in the IDE, not when running the program... Also the Delphi
environment only displays the message when I have the control selected and
click on the form... So my guess is that the Delphi IDE doesn't allow the
canvas to be draw at design time, though the control forces to... I also have
another control, which uses the Paint method, but it also has the same
problem... Also when I do the same stuff as described above...
Lord Havelock Vetinari, the patrician
message handler. I filtered it out, and found an easy solution for it. The
problem in fact was that my control needed to process all messages before
drawing, or it would draw wrongly. However, this caused a "Canvas does not
allow drawing error" in the Delphi IDE. So what I did was, define a "If"
statement, which check if the control was in design mode:
if not (csDesigning in ComponentState) then
Application.ProcessMessage;
As you'll notice, the Application.ProcessMessages gets executed at runtime,
though not at design time...
"Rick Rogers (TeamB)" wrote:
> > Well, my component doesn't have a
>
> This is a pretty confusing list to sort through, especially since a lot of
> it may be unrelated to your problem, and also since you may be leaving out
> critical details that are related to your problem. My suggestion: create a
> small simplified component which does nothing but demonstrate the problem,
> then post it here.
>
> > Which handle should I check for: the one of the control (to see if it has
> > been created)
>
> I believe that it always safe to draw on a control's canvas when the
> control's handle has been allocated, which is what HandleAllocated tells
> you.
>
> > How do you call it, when you expand the hyrarchy by one... ??
> > I always tend to call it derifate, because it comes from "derive"
>
Rick Rogers (TeamB)
message news:378B9B2A...@Hotmail.com...
> The solution was in a Application.ProcessMessages call inside a WM_NCPAINT
This may have worked around the problem, but it is highly unorthodox and
probably hasn't actually solved the problem. But since you haven't provided
enough details for us to speculate on the real source of the problem, we'll
have to leave it at that.
- Rick