[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with __plt_get_axis_arg__.m
From: |
David Bateman |
Subject: |
Re: Problem with __plt_get_axis_arg__.m |
Date: |
Mon, 03 Dec 2007 12:17:09 +0100 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
Michael Goffioul wrote:
> On 12/3/07, David Bateman <address@hidden> wrote:
>
>> Ouch.. Ok I think I see what you are getting at, but its my belief that
>> __patch__ should expect only an axes handles, and the the hggroup should
>> be handled in patch.. Looking at
>>
>> http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/ref/patch.html
>>
>> there isn't supposed to be a manner to call patch with an hggroup or in
>> fact an axes handle..
>>
>
> Indeed...
>
> I think I was misled by this first argument to the patch function, assuming
> it should be the way to specify the patch's parent. Actually, I think the
> parent, if specified, should be given through the property/value pairs and
> not as first argument of patch.m. This seems to be valid for all core
> objects (line, patch, image, light, text, hggroup and hgtransform).
>
> Then I know I'll face another problem in JHandles (which I was trying
> to handle with this first argument of patch). In my current implementation,
> the parent of an object should be known at creation-time: reparenting is
> not really supported yet. In the graphics code, the current pattern is
> to create an empty object (e.g. __go_patch__()) and then fill its properties.
> To have more flexibility (and also avoid current reparenting issues),
> I'd like to have the object creation function called with all init properties,
> instead of the current 2-step process. Is this feasible?
>
> Note: this also would provide more efficient JHandle code, because
> listeners are not active at creation-time. So doing
>
> h = __ go_patch__ ();
> set (h, "facevertex", fv);
>
> is slower than doing
>
> h = __go_patch__ ("facevertex", fv);
>
> Michael.
>
>
Looking in the code in
static octave_value
make_graphics_object (const std::string& go_name,
const octave_value_list& args)
it seems it is supposed to do that already. Something like
h = __go_patch__ (gca(), "Facecolor", "Red")
seems to work fine
D.
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
- Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/01
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/01
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/02
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/02
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/02
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m,
David Bateman <=
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, John W. Eaton, 2007/12/03
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/04
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/06
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/10
- Re: Problem with __plt_get_axis_arg__.m, Michael Goffioul, 2007/12/10
- Re: Problem with __plt_get_axis_arg__.m, David Bateman, 2007/12/10
- Re: Problem with __plt_get_axis_arg__.m, John W. Eaton, 2007/12/10