[erlang-bugs] wxNotebook and wx_object

Dan Gudmundsson dangud@REDACTED
Sun Sep 27 12:08:37 CEST 2009


Hi

wx(Erlang) is just an erlang port of wxWidgets, it marshals the arguments and
make the corresponding C++ calls and so it behaves exactly the same as the
original wxWidgets.

Thus since wxWidgets is coded in C++ everything in wx starts from 0 and not 1.

I can't answer the first question since it's not a feature of wxErlang
you have to
send those kind of questions to wxWidgets list, I'm no expert of the
implementation
of wxWidgets.

Also I don't think you can depend on that behavior (unless it's
documented) for all
platforms.

Question 2, is should mimic the gen_server behavior, I'll have a look
how it's handled
there.

/Dan

On Sun, Sep 27, 2009 at 11:41 AM, Mazen Harake
<mazen.harake@REDACTED> wrote:
> Hi,
>
> Before I post a patch to erlang-patches I was just wondering if it these two
> things are intended behaviour:
>
> 1) If I add  a Panel to Notebook (as a page) and then destroy the Panel, I
> can then ask for the panel on the same index (wxNotebook:getPage/2) and get
> a different panel. further more, if I have added a panel and then ask for an
> index outside of the number of panels I get a new Panel which I never
> created. Also, why does the page index start at 0 when everything else in
> Erlang is 1 based (pretty much).
>
> E.g:
> Nb = wxNotebook:new(Parent, ?wxID_ANY, []),
> Panel = wxPanel:new(),
> wxNotebook:addPage(Nb, Panel, "Whatever", []), %% this is the first page
> added
> P1 = wxNotebook:getPage(Nb, 0), %% this gives the first page added (Panel),
> PUnknown = wxNotebook:getPage(Nb, 1), %% this gives a new page... why?
> shouldn't it crash or something?
> wxPanel:destroy(Panel), %% delete the panel
> P2 = wxNotebook:getPage(Nb, 0),
> %% P1 /= P2 /= PUnknown
>
> Is this intended behaviour? I don't have a patch for this because I don't
> know what is expected
>
> 2) firstly, when calling wx_object:start_link/X and returning {stop,
> whatever} it exits the process. Why?
> second, it patternmatches the return value (from the ack) to {ok, Pid},
> again: Why? This causes the return value to exit with badmatch, I'm sure
> that is not intended? Or is it?
>
> /Mazen
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>
>


More information about the erlang-bugs mailing list