wxlua-users Mailing List for wxLua

Hi,
John Labenski wrote:
> On Nov 30, 2007 2:45 AM, Hakkı Doğusan <hd...@do...> wrote:
>> Hi,
>>
>> (It seems I can post with this mail address)
>>
>> In unittest you'll see following lines (at ~229):
>>
>> a = wx.wxRect(1,2,3,4);
>> function a.Print(self) return string.format("%d,%d,%d,%d", self:GetX(),
>> self:GetY(), self:GetWidth(), self:GetHeight()) end
>> PrintOk(a:Print() == "1,2,3,4", "Add a new lua function to an already
>> created wx.wxRect")
>>
>> I found that usage "trick" from the hard way :) I should have study
>> samples carefully..
> 
> I don't understand your program. Is there something wrong with the
> code or are you showing how to make "executable" modules? The
> executable module method is nice.
> 
I hope there is no problem in my code :)
I'm trying to apply cpp coding style to my lua code. Before finding that 
it is possible to attach addidional fields to wxLua's objects, I was 
using lua tables:
o = { wxobj=nil, fun1=function() .. end }
But using wxLua's object makes it simple.
wxobj.fun1 = function(t) .. end
Similar to x.cpp & x.h usage, I now have x.lua for a X class; clean 
seperation/interface for public and private parts. Using __call method 
as constructor made my modules very similar to cpp classes:
class X : public wxPanel {
public:
 X(wxWindow* parent);
 DoSomething() { DoPrivateThing(); }
private:
 DoPrivateThing();
}
Became;
module"X"
local function DoPrivateThing(t) end
function __call(self, parent)
 local o=wx.wxPanel(parent)
 o.DoSomething=function(t) DoPrivateThing(t) end
 return o
end
setmetatable(_M, _M)
Now both cpp and lua code looks similar:
cpp: o = X(p); o.DoSomething(); o.SetSize(..)
lua: o = X(p); o:DoSomething(); o:SetSize(..)
Hope I successed to explain my thinking..
> Regards,
> John
> 
> 
--
Regards,
Hakki Dogusan

T24gTm92IDMwLCAyMDA3IDI6NDUgQU0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKPiBIaSwKPgo+IChJdCBzZWVtcyBJIGNhbiBwb3N0IHdpdGggdGhpcyBtYWlsIGFkZHJl
c3MpCj4KPiBJbiB1bml0dGVzdCB5b3UnbGwgc2VlIGZvbGxvd2luZyBsaW5lcyAoYXQgfjIyOSk6
Cj4KPiBhID0gd3gud3hSZWN0KDEsMiwzLDQpOwo+IGZ1bmN0aW9uIGEuUHJpbnQoc2VsZikgcmV0
dXJuIHN0cmluZy5mb3JtYXQoIiVkLCVkLCVkLCVkIiwgc2VsZjpHZXRYKCksCj4gc2VsZjpHZXRZ
KCksIHNlbGY6R2V0V2lkdGgoKSwgc2VsZjpHZXRIZWlnaHQoKSkgZW5kCj4gUHJpbnRPayhhOlBy
aW50KCkgPT0gIjEsMiwzLDQiLCAiQWRkIGEgbmV3IGx1YSBmdW5jdGlvbiB0byBhbiBhbHJlYWR5
Cj4gY3JlYXRlZCB3eC53eFJlY3QiKQo+Cj4gSSBmb3VuZCB0aGF0IHVzYWdlICJ0cmljayIgZnJv
bSB0aGUgaGFyZCB3YXkgOikgSSBzaG91bGQgaGF2ZSBzdHVkeQo+IHNhbXBsZXMgY2FyZWZ1bGx5
Li4KCkkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIHByb2dyYW0uIElzIHRoZXJlIHNvbWV0aGluZyB3
cm9uZyB3aXRoIHRoZQpjb2RlIG9yIGFyZSB5b3Ugc2hvd2luZyBob3cgdG8gbWFrZSAiZXhlY3V0
YWJsZSIgbW9kdWxlcz8gVGhlCmV4ZWN1dGFibGUgbW9kdWxlIG1ldGhvZCBpcyBuaWNlLgoKUmVn
YXJkcywKICAgIEpvaG4KCgoKPgo+Cj4gLS0KPiBSZWdhcmRzLAo+IEhha2tpIERvZ3VzYW4KPgo+
Cj4gLS0gODwgLS1bWyB2ZXJ5bWluaW1hbGZyYW1lLmx1YSBdXS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tCj4gbG9jYWwgd3ggPSB3eAo+IGxvY2FsIHNldG1ldGF0YWJsZSA9IHNl
dG1ldGF0YWJsZQo+IGxvY2FsIHJlcXVpcmUgPSByZXF1aXJlCj4gbG9jYWwgbW9kdWxlID0gbW9k
dWxlCj4gbG9jYWwgdG9zdHJpbmcgPSB0b3N0cmluZwo+IG1vZHVsZSJ2ZXJ5bWluaW1hbGZyYW1l
Igo+Cj4gbG9jYWwgZnVuY3Rpb24gU2F5U29tZXRoaW5nRWxzZSh0LCBzKQo+ICAgICAgd3gud3hN
ZXNzYWdlQm94KHRvc3RyaW5nKHQpIC4uICJcbiIgLi4KPiAgICAgICAgICAgIkhlbGxvIGFnYWlu
LCAiIC4uIChzIG9yICIiKSwKPiAgICAgICAgICAgInd4THVhIiwgd3gud3hPSywgdCkKPiBlbmQK
Pgo+IGxvY2FsIGZ1bmN0aW9uIGNyZWF0ZShwYXJlbnQsIGlkLCB0aXRsZSwgcG9zLCBzaXplLCBz
dHlsZSkKPiAgICAgIGxvY2FsIHBhcmVudCA9IHBhcmVudCBvciB3eC5OVUxMCj4gICAgICBsb2Nh
bCBpZCA9IGlkIG9yIHd4Lnd4SURfQU5ZCj4gICAgICBsb2NhbCB0aXRsZSA9IHRpdGxlIG9yICJ3
eEx1YSBWZXJ5IE1pbmltYWwgRGVtbyIKPiAgICAgIGxvY2FsIHBvcyA9IHBvcyBvciB3eC53eERl
ZmF1bHRQb3NpdGlvbgo+ICAgICAgbG9jYWwgc2l6ZSA9IHNpemUgb3Igd3gud3hTaXplKDQ1MCwg
NDUwKQo+ICAgICAgbG9jYWwgc3R5bGUgPSBzdHlsZSBvciB3eC53eERFRkFVTFRfRlJBTUVfU1RZ
TEUKPiAgICAgIGxvY2FsIGZyYW1lID0gd3gud3hGcmFtZSggcGFyZW50LCBpZCwgdGl0bGUsIHBv
cywgc2l6ZSwgc3R5bGUpCj4gICAgICAtLSBhdHRhY2ggc29tZSBtZXRob2RzCj4gICAgICBmcmFt
ZS5TYXlTb21ldGhpbmcgPSBmdW5jdGlvbih0LCBzKQo+ICAgICAgICAgICB3eC53eE1lc3NhZ2VC
b3godG9zdHJpbmcodCkgLi4gIlxuIiAuLgo+ICAgICAgICAgICAgICAiSGVsbG8sICIgLi4gKHMg
b3IgIiIpIC4uICJcbiIgLi4KPiAgICAgICAgICAgICAgdC5tX3ZhciwgInd4THVhIiwgd3gud3hP
SywgdCkKPiAgICAgICAgZW5kCj4gICAgICBmcmFtZS5TYXlTb21ldGhpbmdFbHNlID0gU2F5U29t
ZXRoaW5nRWxzZQo+ICAgICAgZnJhbWUubV92YXIgPSAiIgo+ICAgICAgcmV0dXJuIGZyYW1lCj4g
ZW5kCj4KPiAtLSBzaW11bGF0ZSBjdG9yCj4gZnVuY3Rpb24gX19jYWxsKHNlbGYsIC4uLikKPiAg
ICAgIHJldHVybiBjcmVhdGUoLi4uKQo+IGVuZAo+IHNldG1ldGF0YWJsZShfTSwgX00pCj4KPiAt
LSA4PCAtLVtbIGFwcGxpY2F0aW9uLmx1YSBdXS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KPiBsb2NhbCB3eCA9IHd4Cj4gbG9jYWwgbW9kdWxlID0gbW9kdWxlCj4gbG9j
YWwgc2V0bWV0YXRhYmxlID0gc2V0bWV0YXRhYmxlCj4gbG9jYWwgcmVxdWlyZSA9IHJlcXVpcmUK
PiBsb2NhbCBtb2R1bGUgPSBtb2R1bGUKPiBtb2R1bGUiYXBwbGljYXRpb24iCj4KPiBsb2NhbCBm
dW5jdGlvbiBSdW4odCwgLi4uKQo+ICAgICAgbG9jYWwgVmVyeU1pbmltYWxGcmFtZSA9IHJlcXVp
cmUidmVyeW1pbmltYWxmcmFtZSIKPiAgICAgIGxvY2FsIGZhID0gVmVyeU1pbmltYWxGcmFtZSgp
Cj4gICAgICBsb2NhbCBmYiA9IFZlcnlNaW5pbWFsRnJhbWUod3guTlVMTCwgLTEsICJUZXN0aW5n
IG1vZHVsZSIpCj4gICAgICBmYTpTaG93KHRydWUpCj4gICAgICBmYjpTaG93KHRydWUpCj4gICAg
ICBmYS5tX3ZhciA9ICJmYSdzIG1lbWJlciB2YXJpYWJsZSAiCj4gICAgICBmYTpTYXlTb21ldGhp
bmcoImZhIikKPiAgICAgIGZiOlNheVNvbWV0aGluZygiZmIiKQo+ICAgICAgZmI6U2F5U29tZXRo
aW5nRWxzZSgiZmIiKQo+ICAgICAgZmE6RGVzdHJveSgpCj4gICAgICAtLWNvbW1lbnRlZCB0byBs
ZWZ0IHNvbWV0aGluZyB0byBzZWUgZmI6RGVzdHJveSgpCj4gZW5kCj4KPiBsb2NhbCBmdW5jdGlv
biBjcmVhdGUoLi4uKQo+ICAgICAgbG9jYWwgYSA9IHt9Cj4gICAgICBhLk9uSW5pdCA9IFJ1bgo+
ICAgICAgcmV0dXJuIGEKPiBlbmQKPgo+IC0tIHNpbXVsYXRlIGN0b3IKPiBmdW5jdGlvbiBfX2Nh
bGwoc2VsZiwgLi4uKQo+ICAgICAgcmV0dXJuIGNyZWF0ZSguLi4pCj4gZW5kCj4gc2V0bWV0YXRh
YmxlKF9NLCBfTSkKPgo+IC0tIDg8IC0tW1sgbWFpbi5sdWEgXV0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IGxvY2FsIHJlcXVpcmUgPSByZXF1aXJlCj4g
bG9jYWwgQXBwID0gcmVxdWlyZSJhcHBsaWNhdGlvbiIKPiBsb2NhbCBhID0gQXBwKCkKPiBhOk9u
SW5pdCgpCj4gLS0gODwgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+Cj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFNGLk5l
dCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFRoZSBGdXR1cmUgb2YgTGludXggQnVzaW5lc3MgV2hp
dGUgUGFwZXIKPiBmcm9tIE5vdmVsbC4gIEZyb20gdGhlIGRlc2t0b3AgdG8gdGhlIGRhdGEgY2Vu
dGVyLCBMaW51eCBpcyBnb2luZwo+IG1haW5zdHJlYW0uICBMZXQgaXQgc2ltcGxpZnkgeW91ciBJ
VCBmdXR1cmUuCj4gaHR0cDovL2FsdGZhcm0ubWVkaWFwbGV4LmNvbS9hZC9jay84ODU3LTUwMzA3
LTE4OTE4LTQKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xwo+IHd4bHVhLXVzZXJzIG1haWxpbmcgbGlzdAo+IHd4bHVhLXVzZXJzQGxpc3RzLnNvdXJjZWZv
cmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3d4
bHVhLXVzZXJzCj4K

VGhhbmtzLCBJJ2xsIGFkZCBpdCBvbmNlIEkgZ2V0IGRvbmUgd2l0aCBzb21lIGNsZWFuaW5nIHVw
IG9mIHRoZSBpdGVtcwp3eEx1YSBjcmVhdGVzIGluIHRoZSBMdWEgcmVnaXN0cnkgdGFibGUuCgot
Sm9obgoKT24gTm92IDMwLCAyMDA3IDI6NDcgQU0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4u
bmV0PiB3cm90ZToKPiBIaSwKPgo+ICh1c2luZyBjdnMsIHdpbnhwLCBtaW5ndykKPgo+IEkgYWRk
ZWQgZm9sbG93aW5nIHRvIHd4Y29yZV9pbWFnZS5pIGxpbmUgfjQ1MCAobWF5IG5vdCBiZSBhIGdv
b2QgcGxhY2UpOgo+Cj4gLy8gaGQuLi4gLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCj4gJWluY2x1ZGUgInd4L2ZzX21lbS5oIgo+
Cj4gJWNsYXNzICVub2NsYXNzaW5mbyB3eE1lbW9yeUZTSGFuZGxlcgo+ICAgICAgLy8gZnJvbSB3
eE1lbW9yeUZTSGFuZGxlckJhc2UKPiAgICAgIC8vIFJlbW92ZSBmaWxlIGZyb20gbWVtb3J5IEZT
IGFuZCBmcmVlIG9jY3VwaWVkIG1lbW9yeQo+ICAgICAgc3RhdGljIHZvaWQgUmVtb3ZlRmlsZShj
b25zdCB3eFN0cmluZyYgZmlsZW5hbWUpOwo+ICAgICAgdmlydHVhbCBib29sIENhbk9wZW4oY29u
c3Qgd3hTdHJpbmcmIGxvY2F0aW9uKTsKPiAgICAgIC8vIGZyb20gd3hNZW1vcnlGU0hhbmRsZXJC
YXNlCj4KPiAgICAgIHN0YXRpYyB2b2lkIEFkZEZpbGUoY29uc3Qgd3hTdHJpbmcmIGZpbGVuYW1l
LCBjb25zdCB3eFN0cmluZyYKPiB0ZXh0ZGF0YSk7Cj4KPiAgICAgIC8vc3RhdGljIHZvaWQgQWRk
RmlsZShjb25zdCB3eFN0cmluZyYgZmlsZW5hbWUsCj4gICAgICAvLyAgICAgICAgICAgICAgICAg
ICAgY29uc3Qgdm9pZCAqYmluYXJ5ZGF0YSwKPiAgICAgIC8vICAgICAgICAgICAgICAgICAgICBz
aXplX3Qgc2l6ZSkKPgo+ICVpZiAld3hjaGt2ZXJfMl84XzUgLy8jaWYgd3hBQklfVkVSU0lPTiA+
PSAyMDgwNQo+ICAgICAgc3RhdGljIHZvaWQgQWRkRmlsZVdpdGhNaW1lVHlwZShjb25zdCB3eFN0
cmluZyYgZmlsZW5hbWUsIGNvbnN0Cj4gd3hTdHJpbmcmIHRleHRkYXRhLCBjb25zdCB3eFN0cmlu
ZyYgbWltZXR5cGUpOwo+Cj4gICAgICAvL3N0YXRpYyB2b2lkIEFkZEZpbGVXaXRoTWltZVR5cGUo
Y29uc3Qgd3hTdHJpbmcmIGZpbGVuYW1lLAo+ICAgICAgLy8gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNvbnN0IHZvaWQgKmJpbmFyeWRhdGEsIHNpemVfdCBzaXplLAo+ICAgICAgLy8g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHd4U3RyaW5nJiBtaW1ldHlwZSkK
PiAlZW5kaWYKPgo+ICVpZiB3eExVQV9VU0Vfd3hJbWFnZSAmJiB3eFVTRV9JTUFHRQo+ICAgICAg
c3RhdGljIHZvaWQgQWRkRmlsZShjb25zdCB3eFN0cmluZyYgZmlsZW5hbWUsIGNvbnN0IHd4SW1h
Z2UmIGltYWdlLAo+IGxvbmcgdHlwZSk7Cj4KPiAgICAgIHN0YXRpYyB2b2lkIEFkZEZpbGUoY29u
c3Qgd3hTdHJpbmcmIGZpbGVuYW1lLCBjb25zdCB3eEJpdG1hcCYKPiBiaXRtYXAsIGxvbmcgdHlw
ZSk7Cj4gJWVuZGlmCj4KPiAlZW5kY2xhc3MKPiAvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCj4KPgo+
IEx1YSBzYW1wbGUgdHJhbnNsYXRlZCBmcm9tIHd4JyBoZWxwOgo+Cj4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+ICAgICAgLS0vKiBYUE0gKi8KPiAgICAgIGxvY2FsIGxvZ29feHBtID0gewo+ICAg
ICAgLS0vKiBjb2x1bW5zIHJvd3MgY29sb3JzIGNoYXJzLXBlci1waXhlbCAqLwo+ICAgICAgIjMy
IDMyIDYgMSIsCj4gICAgICAiICBjIGJsYWNrIiwKPiAgICAgICIuIGMgbmF2eSIsCj4gICAgICAi
WCBjIHJlZCIsCj4gICAgICAibyBjIHllbGxvdyIsCj4gICAgICAiTyBjIGdyYXkxMDAiLAo+ICAg
ICAgIisgYyBOb25lIiwKPiAgICAgIC0tLyogcGl4ZWxzICovCj4gICAgICAiKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysiLAo+ICAgICAgIisrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrIiwKPiAgICAgICIrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKyIsCj4gICAg
ICAiKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysiLAo+ICAgICAgIisrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrIiwKPiAgICAgICIrKysrKysrKyAgICAgICAgICAgICAgKysr
KysrKysrKyIsCj4gICAgICAiKysrKysrKysgLi4uLi4uLi4uLi4uICsrKysrKysrKysiLAo+ICAg
ICAgIisrKysrKysrIC4uLi4uLi4uLi4uLiArKysrKysrKysrIiwKPiAgICAgICIrKysrKysrKyAu
T08uLi4uLi4uLi4gKysrKysrKysrKyIsCj4gICAgICAiKysrKysrKysgLk9PLi4uLi4uLi4uICsr
KysrKysrKysiLAo+ICAgICAgIisrKysrKysrIC5PTy4uLi4uLi4uLiArKysrKysrKysrIiwKPiAg
ICAgICIrKysrKysrKyAuT08uLi4uLi4gICAgICAgICAgICAgICIsCj4gICAgICAiKysrKysrKysg
Lk9PLi4uLi4uIG9vb29vb29vb29vbyAiLAo+ICAgICAgIiAgICAgICAgIC5PTy4uLi4uLiBvb29v
b29vb29vb28gIiwKPiAgICAgICIgWFhYWFhYWCAuT08uLi4uLi4gb09Pb29vb29vb29vICIsCj4g
ICAgICAiIFhYWFhYWFggLk9PLi4uLi4uIG9PT29vb29vb29vbyAiLAo+ICAgICAgIiBYT09YWFhY
IC4uLi4uLi4uLiBvT09vb29vb29vb28gIiwKPiAgICAgICIgWE9PWFhYWCAuLi4uLi4uLi4gb09P
b29vb29vb29vICIsCj4gICAgICAiIFhPT1hYWFggICAgICAgICAgIG9PT29vb29vb29vbyAiLAo+
ICAgICAgIiBYT09YWFhYWFhYWFggKysrKyBvT09vb29vb29vb28gIiwKPiAgICAgICIgWE9PWFhY
WFhYWFhYICsrKysgb09Pb29vb29vb29vICIsCj4gICAgICAiIFhPT1hYWFhYWFhYWCArKysrIG9P
T29vb29vb29vbyAiLAo+ICAgICAgIiBYT09YWFhYWFhYWFggKysrKyBvb29vb29vb29vb28gIiwK
PiAgICAgICIgWE9PWFhYWFhYWFhYICsrKysgb29vb29vb29vb29vICIsCj4gICAgICAiIFhYWFhY
WFhYWFhYWCArKysrICAgICAgICAgICAgICAiLAo+ICAgICAgIiBYWFhYWFhYWFhYWFggKysrKysr
KysrKysrKysrKysrIiwKPiAgICAgICIgICAgICAgICAgICAgICsrKysrKysrKysrKysrKysrKyIs
Cj4gICAgICAiKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysiLAo+ICAgICAgIisrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrIiwKPiAgICAgICIrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKyIsCj4gICAgICAiKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysi
LAo+ICAgICAgIisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrIn07Cj4KPiAgICAgIC0t
d3hCdXN5Q3Vyc29yIGJjdXI7Cj4gICAgICAtLWFscmVhZHkgY2FsbGVkIGJ5IGNwcDoKPiAgICAg
IC0td3hGaWxlU3lzdGVtOjpBZGRIYW5kbGVyKG5ldyB3eE1lbW9yeUZTSGFuZGxlcik7Cj4KPiAg
ICAgIHd4Lnd4TWVtb3J5RlNIYW5kbGVyLkFkZEZpbGUoImxvZ28ueHBtIiwgd3gud3hCaXRtYXAo
bG9nb194cG0pLAo+IHd4Lnd4QklUTUFQX1RZUEVfWFBNKTsKPiAgICAgIHd4Lnd4TWVtb3J5RlNI
YW5kbGVyLkFkZEZpbGUoImFib3V0Lmh0bSIsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAiPGh0bWw+PGJvZHk+QWJvdXQ6ICIgLi4KPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICI8aW1nCj4gc3JjPVwibWVtb3J5OmxvZ28ueHBtXCI+PC9ib2R5PjwvaHRtbD4iKTsK
Pgo+ICAgICAgbG9jYWwgZGxnID0gd3gud3hEaWFsb2cod3guTlVMTCwgLTEsICJBYm91dCIpOwo+
ICAgICAgbG9jYWwgdG9wc2l6ZXIgPSB3eC53eEJveFNpemVyKHd4Lnd4VkVSVElDQUwpOwo+ICAg
ICAgbG9jYWwgaHRtbCA9IHd4Lnd4SHRtbFdpbmRvdyhkbGcsIC0xLCB3eC53eERlZmF1bHRQb3Np
dGlvbiwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHd4Lnd4U2l6ZSgzODAsIDE2MCks
IHd4Lnd4SFdfU0NST0xMQkFSX05FVkVSKTsKPiAgICAgIGh0bWw6U2V0Qm9yZGVycygwKTsKPiAg
ICAgIGh0bWw6TG9hZFBhZ2UoIm1lbW9yeTphYm91dC5odG0iKTsKPiAgICAgIGh0bWw6U2V0U2l6
ZShodG1sOkdldEludGVybmFsUmVwcmVzZW50YXRpb24oKTpHZXRXaWR0aCgpLAo+ICAgICAgICAg
ICAgICAgICAgICBodG1sOkdldEludGVybmFsUmVwcmVzZW50YXRpb24oKTpHZXRIZWlnaHQoKSk7
Cj4gICAgICB0b3BzaXplcjpBZGQoaHRtbCwgMSwgd3gud3hBTEwsIDEwKTsKPiAgICAgIHRvcHNp
emVyOkFkZCh3eC53eFN0YXRpY0xpbmUoZGxnLCAtMSksIDAsIHd4Lnd4RVhQQU5EICsgd3gud3hM
RUZUICsKPiB3eC53eFJJR0hULCAxMCk7Cj4gICAgICB0b3BzaXplcjpBZGQod3gud3hCdXR0b24o
ZGxnLCB3eC53eElEX09LLCAiT2siKSwKPiAgICAgICAgICAgICAgICAgICAgMCwgd3gud3hBTEwg
KyB3eC53eEFMSUdOX1JJR0hULCAxNSk7Cj4gICAgICBkbGc6U2V0QXV0b0xheW91dCh0cnVlKTsK
PiAgICAgIGRsZzpTZXRTaXplcih0b3BzaXplcik7Cj4gICAgICB0b3BzaXplcjpGaXQoZGxnKTsK
PiAgICAgIGRsZzpDZW50cmUoKTsKPiAgICAgIGRsZzpTaG93TW9kYWwoKTsKPiAgICAgIGRsZzpE
ZXN0cm95KCk7Cj4KPiAgICAgIHd4Lnd4TWVtb3J5RlNIYW5kbGVyLlJlbW92ZUZpbGUoImxvZ28u
eHBtIik7Cj4gICAgICB3eC53eE1lbW9yeUZTSGFuZGxlci5SZW1vdmVGaWxlKCJhYm91dC5odG0i
KTsKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+IC0tCj4gUmVnYXJkcywKPiBIYWtraSBE
b2d1c2FuCj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVk
IGJ5OiBUaGUgRnV0dXJlIG9mIExpbnV4IEJ1c2luZXNzIFdoaXRlIFBhcGVyCj4gZnJvbSBOb3Zl
bGwuICBGcm9tIHRoZSBkZXNrdG9wIHRvIHRoZSBkYXRhIGNlbnRlciwgTGludXggaXMgZ29pbmcK
PiBtYWluc3RyZWFtLiAgTGV0IGl0IHNpbXBsaWZ5IHlvdXIgSVQgZnV0dXJlLgo+IGh0dHA6Ly9h
bHRmYXJtLm1lZGlhcGxleC5jb20vYWQvY2svODg1Ny01MDMwNy0xODkxOC00Cj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiB3eGx1YS11c2VycyBtYWls
aW5nIGxpc3QKPiB3eGx1YS11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBodHRwczovL2xp
c3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby93eGx1YS11c2Vycwo+Cg==

T24gTm92IDMwLCAyMDA3IDU6MjggUE0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKPiBIaSwKPgo+IEpvaG4gTGFiZW5za2kgd3JvdGU6Cj4gPiBJIGJlbGlldmUgdGhhdCB3
ZSBoYXZlIHNlbmRlciBob3N0bmFtZSBsb29rdXAgdHVybmVkIG9uIHRvIGF2b2lkIHNwYW0KPiA+
IG1haWwuIEhvd2V2ZXIsIHNpbmNlIHdlJ3ZlIHN3aXRjaGVkIHRvIGEgc3Vic2NyaXB0aW9uIGxp
c3Qgd2UgZG9uJ3QKPiA+IGdldCBhbnkgbW9yZSBzcGFtLgo+ID4KPgo+IEl0IHNlZW1zIHByb2Js
ZW0gaXMgbm90IHd4bHVhIGxpc3Qgb25seS4gSSBqb2luZWQgZmxhbWVyb2JpbidzIGxpc3Qgd2l0
aAo+ICAgdGhpcyBtYWlsIGFkZHJlc3MgYW5kIGdldCBtZXNzYWdlcy4gU2luY2UgdGhlcmUgaXMg
bm90IG11Y2ggYWN0aXZpdHkKPiB0aGVyZSwgSSBkaWRuJ3Qgbm90aWNlIHRoZSBwcm9ibGVtLgo+
Cj4gSSd2ZSBjcmVhdGVkIGFuIGVudHJ5IGZvciBteSBwcm9ibGVtIGF0IHNvdXJjZWZvcmdlJ3Mg
dHJhY2tlci4KClNvdW5kcyBiZXN0LCB3cml0ZSBiYWNrIGlmIGl0J3Mgbm90IHJlc29sdmVkIGJ5
IHNvdXJjZWZvcmdlLgoKUmVnYXJkcywKICAgIEpvaG4K

Hi,
John Labenski wrote:
> I believe that we have sender hostname lookup turned on to avoid spam
> mail. However, since we've switched to a subscription list we don't
> get any more spam.
> 
> How is "tr.net"? Are they reasonably large?
> 
> I guess we could turn it off if it's really a problem.
> 
> Regards,
> John
> 
> 
It seems problem is not wxlua list only. I joined flamerobin's list with 
 this mail address and get messages. Since there is not much activity 
there, I didn't notice the problem.
I've created an entry for my problem at sourceforge's tracker.
--
Regards,
Hakki Dogusan

Hi,
John Labenski wrote:
> I believe that we have sender hostname lookup turned on to avoid spam
> mail. However, since we've switched to a subscription list we don't
> get any more spam.
> 
> How is "tr.net"? Are they reasonably large?
> 
This is Turkey's main internet thing.. One can get ".tr" name from them 
only.
> I guess we could turn it off if it's really a problem.
> 
Did you change conf around 2007年11月16日 ? My first rejected mail was sent 
at that day.
If possible, I prefer to use my main mail address, thanks.
> Regards,
> John
> 
> 
--
Regards,
Hakki Dogusan

SSBiZWxpZXZlIHRoYXQgd2UgaGF2ZSBzZW5kZXIgaG9zdG5hbWUgbG9va3VwIHR1cm5lZCBvbiB0
byBhdm9pZCBzcGFtCm1haWwuIEhvd2V2ZXIsIHNpbmNlIHdlJ3ZlIHN3aXRjaGVkIHRvIGEgc3Vi
c2NyaXB0aW9uIGxpc3Qgd2UgZG9uJ3QKZ2V0IGFueSBtb3JlIHNwYW0uCgpIb3cgaXMgInRyLm5l
dCI/IEFyZSB0aGV5IHJlYXNvbmFibHkgbGFyZ2U/CgpJIGd1ZXNzIHdlIGNvdWxkIHR1cm4gaXQg
b2ZmIGlmIGl0J3MgcmVhbGx5IGEgcHJvYmxlbS4KClJlZ2FyZHMsCiAgICBKb2huCgoKT24gTm92
IDMwLCAyMDA3IDI6MzkgQU0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3cm90ZToK
PiBIaSwKPgo+IExhdGVseSBteSBtZXNzYWdlcyB0byBsaXN0IGNvbWluZyBiYWNrIHdpdGggdGhl
IGZvbGxvd2luZzoKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVW5kZWxpdmVyZWQgTWFpbCBSZXR1cm5lZCB0
byBTZW5kZXIKPgo+IDx3eGx1YS11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+OiBob3N0Cj4g
bWFpbC5zb3VyY2Vmb3JnZS5uZXRbNjYuMzUuMjUwLjIwNl0KPiAgICAgIHNhaWQ6IDQ1MS1ob3N0
IGxvb2t1cCBkaWQgbm90IGNvbXBsZXRlIDQ1MSBDb3VsZCBub3QgY29tcGxldGUKPiBzZW5kZXIg
dmVyaWZ5Cj4gICAgICAoaW4gcmVwbHkgdG8gUkNQVCBUTyBjb21tYW5kKQo+Cj4gUmVwb3J0aW5n
LU1UQTogZG5zOyBzbXRwMi50ci5uZXQKPiBYLVBvc3RmaXgtUXVldWUtSUQ6IDk4NEEwNDE3Rgo+
IFgtUG9zdGZpeC1TZW5kZXI6IHJmYzgyMjsgZG9ndXNhbmhAdHIubmV0Cj4gQXJyaXZhbC1EYXRl
OiBUaHUsIDI5IE5vdiAyMDA3IDE2OjQzOjQ2ICswMjAwIChFRVQpCj4gQ29udGVudC1UeXBlOiB0
ZXh0L3BsYWluCj4KPiBGaW5hbC1SZWNpcGllbnQ6IHJmYzgyMjsgd3hsdWEtdXNlcnNAbGlzdHMu
c291cmNlZm9yZ2UubmV0Cj4gQWN0aW9uOiBmYWlsZWQKPiBTdGF0dXM6IDQuMC4wCj4gRGlhZ25v
c3RpYy1Db2RlOiBYLVBvc3RmaXg7IGhvc3QgbWFpbC5zb3VyY2Vmb3JnZS5uZXRbNjYuMzUuMjUw
LjIwNl0gc2FpZDoKPiAgICAgIDQ1MS1ob3N0IGxvb2t1cCBkaWQgbm90IGNvbXBsZXRlIDQ1MSBD
b3VsZCBub3QgY29tcGxldGUgc2VuZGVyCj4gdmVyaWZ5IChpbgo+ICAgICAgcmVwbHkgdG8gUkNQ
VCBUTyBjb21tYW5kKQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+IERvIHlvdSBrbm93IHdoeT8KPgo+Cj4g
LS0KPiBSZWdhcmRzLAo+IEhha2tpIERvZ3VzYW4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBTRi5O
ZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBUaGUgRnV0dXJlIG9mIExpbnV4IEJ1c2luZXNzIFdo
aXRlIFBhcGVyCj4gZnJvbSBOb3ZlbGwuICBGcm9tIHRoZSBkZXNrdG9wIHRvIHRoZSBkYXRhIGNl
bnRlciwgTGludXggaXMgZ29pbmcKPiBtYWluc3RyZWFtLiAgTGV0IGl0IHNpbXBsaWZ5IHlvdXIg
SVQgZnV0dXJlLgo+IGh0dHA6Ly9hbHRmYXJtLm1lZGlhcGxleC5jb20vYWQvY2svODg1Ny01MDMw
Ny0xODkxOC00Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KPiB3eGx1YS11c2VycyBtYWlsaW5nIGxpc3QKPiB3eGx1YS11c2Vyc0BsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby93
eGx1YS11c2Vycwo+Cg==

Hi,
(using cvs, winxp, mingw)
I added following to wxcore_image.i line ~450 (may not be a good place):
// hd... ///////////////////////////////////////////////////////////////
%include "wx/fs_mem.h"
%class %noclassinfo wxMemoryFSHandler
 // from wxMemoryFSHandlerBase
 // Remove file from memory FS and free occupied memory
 static void RemoveFile(const wxString& filename);
 virtual bool CanOpen(const wxString& location);
 // from wxMemoryFSHandlerBase
 static void AddFile(const wxString& filename, const wxString& 
textdata);
 //static void AddFile(const wxString& filename,
 // const void *binarydata,
 // size_t size)
%if %wxchkver_2_8_5 //#if wxABI_VERSION >= 20805
 static void AddFileWithMimeType(const wxString& filename, const 
wxString& textdata, const wxString& mimetype);
 //static void AddFileWithMimeType(const wxString& filename,
 // const void *binarydata, size_t size,
 // const wxString& mimetype)
%endif
%if wxLUA_USE_wxImage && wxUSE_IMAGE
 static void AddFile(const wxString& filename, const wxImage& image, 
long type);
 static void AddFile(const wxString& filename, const wxBitmap& 
bitmap, long type);
%endif
%endclass
///////////////////////////////////////////////////////////////////////////////
Lua sample translated from wx' help:
-------------------------------------------------------------------------------
 --/* XPM */
 local logo_xpm = {
 --/* columns rows colors chars-per-pixel */
 "32 32 6 1",
 " c black",
 ". c navy",
 "X c red",
 "o c yellow",
 "O c gray100",
 "+ c None",
 --/* pixels */
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++ ++++++++++",
 "++++++++ ............ ++++++++++",
 "++++++++ ............ ++++++++++",
 "++++++++ .OO......... ++++++++++",
 "++++++++ .OO......... ++++++++++",
 "++++++++ .OO......... ++++++++++",
 "++++++++ .OO...... ",
 "++++++++ .OO...... oooooooooooo ",
 " .OO...... oooooooooooo ",
 " XXXXXXX .OO...... oOOooooooooo ",
 " XXXXXXX .OO...... oOOooooooooo ",
 " XOOXXXX ......... oOOooooooooo ",
 " XOOXXXX ......... oOOooooooooo ",
 " XOOXXXX oOOooooooooo ",
 " XOOXXXXXXXXX ++++ oOOooooooooo ",
 " XOOXXXXXXXXX ++++ oOOooooooooo ",
 " XOOXXXXXXXXX ++++ oOOooooooooo ",
 " XOOXXXXXXXXX ++++ oooooooooooo ",
 " XOOXXXXXXXXX ++++ oooooooooooo ",
 " XXXXXXXXXXXX ++++ ",
 " XXXXXXXXXXXX ++++++++++++++++++",
 " ++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++",
 "++++++++++++++++++++++++++++++++"};
 --wxBusyCursor bcur;
 --already called by cpp:
 --wxFileSystem::AddHandler(new wxMemoryFSHandler);
 wx.wxMemoryFSHandler.AddFile("logo.xpm", wx.wxBitmap(logo_xpm), 
wx.wxBITMAP_TYPE_XPM);
 wx.wxMemoryFSHandler.AddFile("about.htm",
 "<html><body>About: " ..
 "<img 
src=\"memory:logo.xpm\"></body></html>");
 local dlg = wx.wxDialog(wx.NULL, -1, "About");
 local topsizer = wx.wxBoxSizer(wx.wxVERTICAL);
 local html = wx.wxHtmlWindow(dlg, -1, wx.wxDefaultPosition,
 wx.wxSize(380, 160), wx.wxHW_SCROLLBAR_NEVER);
 html:SetBorders(0);
 html:LoadPage("memory:about.htm");
 html:SetSize(html:GetInternalRepresentation():GetWidth(),
 html:GetInternalRepresentation():GetHeight());
 topsizer:Add(html, 1, wx.wxALL, 10);
 topsizer:Add(wx.wxStaticLine(dlg, -1), 0, wx.wxEXPAND + wx.wxLEFT + 
wx.wxRIGHT, 10);
 topsizer:Add(wx.wxButton(dlg, wx.wxID_OK, "Ok"),
 0, wx.wxALL + wx.wxALIGN_RIGHT, 15);
 dlg:SetAutoLayout(true);
 dlg:SetSizer(topsizer);
 topsizer:Fit(dlg);
 dlg:Centre();
 dlg:ShowModal();
 dlg:Destroy();
 wx.wxMemoryFSHandler.RemoveFile("logo.xpm");
 wx.wxMemoryFSHandler.RemoveFile("about.htm");
-------------------------------------------------------------------------------
-- 
Regards,
Hakki Dogusan

Hi,
(It seems I can post with this mail address)
In unittest you'll see following lines (at ~229):
a = wx.wxRect(1,2,3,4);
function a.Print(self) return string.format("%d,%d,%d,%d", self:GetX(), 
self:GetY(), self:GetWidth(), self:GetHeight()) end
PrintOk(a:Print() == "1,2,3,4", "Add a new lua function to an already 
created wx.wxRect")
I found that usage "trick" from the hard way :) I should have study 
samples carefully..
-- 
Regards,
Hakki Dogusan
-- 8< --[[ veryminimalframe.lua ]]-----------------------------------
local wx = wx
local setmetatable = setmetatable
local require = require
local module = module
local tostring = tostring
module"veryminimalframe"
local function SaySomethingElse(t, s)
 wx.wxMessageBox(tostring(t) .. "\n" ..
 "Hello again, " .. (s or ""),
 "wxLua", wx.wxOK, t)
end
local function create(parent, id, title, pos, size, style)
 local parent = parent or wx.NULL
 local id = id or wx.wxID_ANY
 local title = title or "wxLua Very Minimal Demo"
 local pos = pos or wx.wxDefaultPosition
 local size = size or wx.wxSize(450, 450)
 local style = style or wx.wxDEFAULT_FRAME_STYLE
 local frame = wx.wxFrame( parent, id, title, pos, size, style)
 -- attach some methods
 frame.SaySomething = function(t, s)
 wx.wxMessageBox(tostring(t) .. "\n" ..
 "Hello, " .. (s or "") .. "\n" ..
 t.m_var, "wxLua", wx.wxOK, t)
 end
 frame.SaySomethingElse = SaySomethingElse
 frame.m_var = ""
 return frame
end
-- simulate ctor
function __call(self, ...)
 return create(...)
end
setmetatable(_M, _M)
-- 8< --[[ application.lua ]]----------------------------------------
local wx = wx
local module = module
local setmetatable = setmetatable
local require = require
local module = module
module"application"
local function Run(t, ...)
 local VeryMinimalFrame = require"veryminimalframe"
 local fa = VeryMinimalFrame()
 local fb = VeryMinimalFrame(wx.NULL, -1, "Testing module")
 fa:Show(true)
 fb:Show(true)
 fa.m_var = "fa's member variable "
 fa:SaySomething("fa")
 fb:SaySomething("fb")
 fb:SaySomethingElse("fb")
 fa:Destroy()
 --commented to left something to see fb:Destroy()
end
local function create(...)
 local a = {}
 a.OnInit = Run
 return a
end
-- simulate ctor
function __call(self, ...)
 return create(...)
end
setmetatable(_M, _M)
-- 8< --[[ main.lua ]]-----------------------------------------------
local require = require
local App = require"application"
local a = App()
a:OnInit()
-- 8< --------------------------------------------------------------

.

That works great.
Thanks,
Darwin
----------------------------------------
> Date: 2007年11月17日 15:22:15 -0500
> From: jla...@gm...
> To: djs...@us...; wxl...@li...
> Subject: Re: [wxlua-users] Problem with enumerations in C++ namespaces
>=20
> All done, the current CVS should work. You have to regenerate your
> bindings to use it.
>=20
> The added benefit is that wxLua is now installed like any other
> library and you can call "require("wx")" even if you're not using it
> as a shared library.
>=20
> Regards,
> John
>=20
> On Nov 13, 2007 3:34 AM, Darwin Slattery wrote:
>>
>>
>>>> I also used the following value for hook_cpp_binding_header_includes:
>>>> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespa=
ce nsa;"
>>>
>>> Good, I hoped it was this simple. Just wondering, why do you need
>>> "namespace nsa {}"? Is it because you're not #including a header that
>>> defines it?
>>
>> Yes, I had only put the necessary %include's in the .i file.
>>
>> Regards,
>> Darwin
>>
>> _________________________________________________________________
>> The next generation of MSN Hotmail has arrived - Windows Live Hotmail
>> http://www.newhotmail.co.uk
>>
>> ------------------------------------------------------------------------=
-
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now>> http://get.splunk.com/
>> _______________________________________________
>> wxlua-users mailing list
>> wxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>>
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=

Thanks, I've added the missing bindings and the sample. I unremmed out
the parts that didn't work before and it seems pretty nice. Let me
know if any other changes need to be made.
Thanks,
 John
On Nov 22, 2007 2:22 AM, Hakki Dogusan <dog...@tr...> wrote:
> Hi,
>
> (I hope you don't get this message twice.)
>
> I tried to translate wx/samples/aui/auidemo.cpp to wxLua. Result is at
> http://www.dogusan.net/dogusanh/download/auidemo.wx.zip (11Kb).
>
> It is in a premature state;
> - I left some bit manupulations commented out
> - wxAuiPaneInfo's fields are not binded by wxLua; cpp demo uses some of
> these public fields directly:
> wxString name; // name of the pane
> wxWindow* window; // window that is in this pane
> int dock_layer; // layer number (0 = innermost layer)
>
>
> --
> Regards,
> Hakki Dogusan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Hi,
(I hope you don't get this message twice.)
I tried to translate wx/samples/aui/auidemo.cpp to wxLua. Result is at 
http://www.dogusan.net/dogusanh/download/auidemo.wx.zip (11Kb).
It is in a premature state;
- I left some bit manupulations commented out
- wxAuiPaneInfo's fields are not binded by wxLua; cpp demo uses some of 
these public fields directly:
wxString name; // name of the pane
wxWindow* window; // window that is in this pane
int dock_layer; // layer number (0 = innermost layer)
-- 
Regards,
Hakki Dogusan

Hi,
John Labenski wrote:
> On Nov 16, 2007 8:47 AM, Hakki Dogusan <dog...@tr...> wrote:
>> Hi,
>>
>> Is it possible to extend wxArtProvider in wxLua? wx's document shows
>> following sample:
>>
>> class MyProvider : public wxArtProvider
>> {
>> protected:
>> wxBitmap CreateBitmap(const wxArtID& id,
>> const wxArtClient& client,
>> const wxSize size)
>> { ... }
>> };
>> ...
>> wxArtProvider::Push(new MyProvider);
>>
> 
> Unfortunately not, a class like wxLuaPrintout that allows overriding
> virtual functions would have to be written. I'll try to remember to do
> it.
> 
> There's a general issue about creating our own classes to allow
> overriding virtual functions however, if we continue to create more
> and more of them we'll end up with a lot of wxLuaXXX classes on top of
> the original XXX classes and that seems awkward to me since you
> shouldn't have to worry about such things in wxLua. It could be made
> transparent by calling them just XXX in Lua, but I think this could be
> a problem if you call a function that returns an XXX class, but wxLua
> only deals with our subclassed wxLuaXXX classes.
> 
> For example: We write wxLuaTreeCtrl so we can override
> OnCompareItems(...) in Lua and as above treat all wxTreeCtrls as
> wxLuaTreeCtrls. Everything is great if all wxTreeCtrls are created in
> wxLua since they'll all be wxLuaTreeCtrls. There's a problem if a user
> uses wxGlade (or whatever) to create XML files for their GUI and then
> they try to get their wxTreeCtrl, but wxLua pushes it as a
> wxLuaTreeCtrl which it's not. The wxGenericDirCtrl creates it's own
> wxTreeCtrl which you can get using wxGenericDirCtrl ::GetTreeCtrl(),
> same problem as above.
> 
> I guess I have to look at wxPython to see how they handle this since I
> know that they subclass quite a few things. Unless maybe someone else
> knows?
> 
> Regards,
> John
> 
It seems wxPython implements wxPyArtProvider and uses it as 
wxArtProvider. Related parts from artprov.i is below:
%{ // Python aware wxArtProvider
class wxPyArtProvider : public wxArtProvider {
public:
 virtual wxBitmap CreateBitmap(const wxArtID& id,
 const wxArtClient& client,
 const wxSize& size) {
 wxBitmap rval = wxNullBitmap;
 wxPyBlock_t blocked = wxPyBeginBlockThreads();
 if ((wxPyCBH_findCallback(m_myInst, "CreateBitmap"))) {
 PyObject* so = wxPyConstructObject((void*)&size, 
wxT("wxSize"), 0);
 PyObject* ro;
 wxBitmap* ptr;
 PyObject* s1, *s2;
 s1 = wx2PyString(id);
 s2 = wx2PyString(client);
 ro = wxPyCBH_callCallbackObj(m_myInst, 
Py_BuildValue("(OOO)", s1, s2, so));
 Py_DECREF(so);
 Py_DECREF(s1);
 Py_DECREF(s2);
 if (ro) {
 if (wxPyConvertSwigPtr(ro, (void**)&ptr, wxT("wxBitmap")))
 rval = *ptr;
 Py_DECREF(ro);
 }
 }
 wxPyEndBlockThreads(blocked);
 return rval;
 }
 PYPRIVATE;
};
%}
%rename(ArtProvider) wxPyArtProvider;
class wxPyArtProvider /*: public wxObject*/
{
public:
 %pythonAppend wxPyArtProvider setCallbackInfo(ArtProvider);
 wxPyArtProvider();
 ~wxPyArtProvider();
 void _setCallbackInfo(PyObject* self, PyObject* _class);
 %disownarg( wxPyArtProvider *provider );
...
 %cleardisown( wxPyArtProvider *provider );
...
 %pythonPrepend Destroy "args[0].this.own(False)"
 %extend { void Destroy() { delete self; }}
};
%init %{
 wxPyPtrTypeMap_Add("wxArtProvider", "wxPyArtProvider");
%}
-- 
Regards,
Hakki Dogusan

On Nov 17, 2007 3:52 PM, Ryan Pusztai <rpu...@gm...> wrote:
>
> I need to start using wxLua in a real project in corperate setting so I
> wanted to know if the build issues with OpenGL are fixed. Also if there is
No, I tried a few things and rebuilt the bakefiles, but when I read
through the output it didn't look right.
Hopefully Francesco will have some time to look at it, but I believe
he's pretty busy these days.
> going to be another Linux and Windows installer?
I personally like the zip files, but there's some code for creating an
installer in wxLua/distrib/innosetup that can be used.
> Now saying this, it seems like I am unhappy and I am not meaning to. I just
> wanted to get your thoughts on a few issues I saw. Thanks for your time and
> patients.
No problem, things take time since I have less and less free time these days.
Regards,
 John

On Nov 16, 2007 8:47 AM, Hakki Dogusan <dog...@tr...> wrote:
> Hi,
>
> Is it possible to extend wxArtProvider in wxLua? wx's document shows
> following sample:
>
> class MyProvider : public wxArtProvider
> {
> protected:
> wxBitmap CreateBitmap(const wxArtID& id,
> const wxArtClient& client,
> const wxSize size)
> { ... }
> };
> ...
> wxArtProvider::Push(new MyProvider);
>
Unfortunately not, a class like wxLuaPrintout that allows overriding
virtual functions would have to be written. I'll try to remember to do
it.
There's a general issue about creating our own classes to allow
overriding virtual functions however, if we continue to create more
and more of them we'll end up with a lot of wxLuaXXX classes on top of
the original XXX classes and that seems awkward to me since you
shouldn't have to worry about such things in wxLua. It could be made
transparent by calling them just XXX in Lua, but I think this could be
a problem if you call a function that returns an XXX class, but wxLua
only deals with our subclassed wxLuaXXX classes.
For example: We write wxLuaTreeCtrl so we can override
OnCompareItems(...) in Lua and as above treat all wxTreeCtrls as
wxLuaTreeCtrls. Everything is great if all wxTreeCtrls are created in
wxLua since they'll all be wxLuaTreeCtrls. There's a problem if a user
uses wxGlade (or whatever) to create XML files for their GUI and then
they try to get their wxTreeCtrl, but wxLua pushes it as a
wxLuaTreeCtrl which it's not. The wxGenericDirCtrl creates it's own
wxTreeCtrl which you can get using wxGenericDirCtrl ::GetTreeCtrl(),
same problem as above.
I guess I have to look at wxPython to see how they handle this since I
know that they subclass quite a few things. Unless maybe someone else
knows?
Regards,
 John

On 9/5/07, Ryan Pusztai <rpu...@gm...> wrote:
>
> On 9/5/07, John Labenski <jla...@gm...> wrote:
> >
> > You're using the wxWidgets monolithic build it seems using mingw?
>
>
> Yes I am using monolithic MinGW.
>
> Do you use "configure" with mingw or just makefile.gcc?
>
>
> I am using the makefile.gcc.
>
> The monolithic
> > build is broken because nobody's checked it. In fact I don't even know
> > what gets put into the monolithic build?
>
>
> Wow. That is not good. You are planning on fixing that, right? I think the
> monolithic dll version is the only way, I personally, would use the dll
> version. I don't like having 6+ dll's as dependencies. I could deal with it
> for static linking, but I figure, that is just more setup and more setting I
> need to set in my main project that will use wxLua. ;-)
>
> If I remember correctly the
> > GL lib is not part of it, just like the jpeg lib isn't. Is there a
> > list somewhere about what is part of the monolithic build so that we
> > can add the extra libs for wxLua to link to?
>
>
> Good question. I don't have a real need for GL so I never use it, so I
> couldn't say. As for jpeg and other image libraries, I think they are
> included in the wx dll. I will check for sure when I get back to work
> tomorrow.
>
> ..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0xc):
> >
> > > undefined reference
> > > to `wxGLCanvas::ms_classInfo'
> >
> > Ok, this says clearly that you need to link to the wxWidgets GL lib
> > since it's not part of -lwxmsw28.
>
>
> I have added that in the location in the makefile where the Bakefile
> named variable is located and I still got the same results. I will double
> verify this tomarrow at work and post the errors.
>
> You should have a wxmsw28_gl.lib file (just like -lwxmsw28_stc) in the
> > wxWidgets lib dir if you've built it.
>
>
> Yes. I definatly have it and it is right next to the other build files.
> What compilers are actively tested? Is it only VC?
>
> I'll try to find some time to look into it again, but I could not
> > figure out how to get bakefile to work right for this before.
>
>
> That is kind of the point I was driving at in my previous email. Your
> project is only as good as your ability to build it.
>
> I should write something about this. There is a little about the
> > modules in the wxlua.html file with some comments on what depends on
> > what. You need modules/wxlua and modules/wxbind at least. The parts of
> > modules/wxbind are exactly like the wxWidgets libs, take the ones you
> > want, typically base, core, adv...
>
>
> That would be a great help. Thanks.
>
> A lot of work has gone into making the bakefiles work as well as they
> > do. I personally have a hard time understanding the XML/python nature
> > of them, but Francesco does and I believe he is still on vacation. I
> > hope he has time to look at this when he gets back. wxLua uses
> > bakefile since that's what wxWidgets uses, if it works for them it
> > should be able to work for us since we target the same systems and
> > compilers.
>
>
> Yes, I understand that. There is a very massive code base for that. It
> makes sense. I just want get a feel for how the project runs.
> --
> Regards,
> Ryan
> RJP Computing
I need to start using wxLua in a real project in corperate setting so I
wanted to know if the build issues with OpenGL are fixed. Also if there is
going to be another Linux and Windows installer?
Now saying this, it seems like I am unhappy and I am not meaning to. I just
wanted to get your thoughts on a few issues I saw. Thanks for your time and
patients.
-- 
Regards,
Ryan
RJP Computing

All done, the current CVS should work. You have to regenerate your
bindings to use it.
The added benefit is that wxLua is now installed like any other
library and you can call "require("wx")" even if you're not using it
as a shared library.
Regards,
 John
On Nov 13, 2007 3:34 AM, Darwin Slattery <dar...@ho...> wrote:
>
>
> >> I also used the following value for hook_cpp_binding_header_includes:
> >> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace nsa;"
> >
> > Good, I hoped it was this simple. Just wondering, why do you need
> > "namespace nsa {}"? Is it because you're not #including a header that
> > defines it?
>
> Yes, I had only put the necessary %include's in the .i file.
>
> Regards,
> Darwin
>
> _________________________________________________________________
> The next generation of MSN Hotmail has arrived - Windows Live Hotmail
> http://www.newhotmail.co.uk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Hi,
Is it possible to extend wxArtProvider in wxLua? wx's document shows 
following sample:
 class MyProvider : public wxArtProvider
 {
 protected:
 wxBitmap CreateBitmap(const wxArtID& id,
 const wxArtClient& client,
 const wxSize size)
 { ... }
 };
 ...
 wxArtProvider::Push(new MyProvider);
I tried as following, but didn't work:
local artprovider = wx.wxArtProvider() --error: attempt to call field
function artprovider:CreateBitmap(id, client, size)
 return wx.wxBitmap(testxpm)
end
wx.wxArtProvider.Push(artprovider)
--
Regards,
Hakki Dogusan

>> I also used the following value for hook_cpp_binding_header_includes:
>> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace=
 nsa;"
>=20
> Good, I hoped it was this simple. Just wondering, why do you need
> "namespace nsa {}"? Is it because you're not #including a header that
> defines it?
Yes, I had only put the necessary %include's in the .i file.
Regards,
Darwin
_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=

On Nov 12, 2007 5:35 PM, Darwin Slattery <dar...@ho...> wrote:
>
> Thanks for your reply.
>
> The approach worked fine but I'd just like to clarify one point. I found that using a hook_lua_namespace of 'wxluanstest.nsa' created a table with this name in adddition to the 'wxluanstest' table i.e. it did not create an 'nsa' table inside the already existing 'wxluanstest' table. I just want to know if this what you expected to happen? I ended up changing the hook_lua_namespace to 'wxluanstest_nsa' so that it wouldn't cause a syntax error in lua.
>
Right, code has to be added to break up hook_lua_namespace by '.' and
the tables created. I wanted to wait to see if there wasn't some
problem with the C++ side before changing anything. I'll try to get
around to it tonight.
> I also used the following value for hook_cpp_binding_header_includes:
> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace nsa;"
Good, I hoped it was this simple. Just wondering, why do you need
"namespace nsa {}"? Is it because you're not #including a header that
defines it?
Regards,
 John

Thanks for your reply.
The approach worked fine but I'd just like to clarify one point. I found th=
at using a hook_lua_namespace of 'wxluanstest.nsa' created a table with thi=
s name in adddition to the 'wxluanstest' table i.e. it did not create an 'n=
sa' table inside the already existing 'wxluanstest' table. I just want to k=
now if this what you expected to happen? I ended up changing the hook_lua_n=
amespace to 'wxluanstest_nsa' so that it wouldn't cause a syntax error in l=
ua.
I also used the following value for hook_cpp_binding_header_includes:
"#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace ns=
a;"
Thanks again for your help,
Darwin
----------------------------------------
> Date: Wed, 7 Nov 2007 19:01:32 -0500
> From: jla...@gm...
> To: djs...@us...; wxl...@li...
> Subject: Re: [wxlua-users] Problem with enumerations in C++ namespaces
>=20
> On 11/6/07, Darwin Slattery wrote:
>>
>> Hello,
>>
>> I have been having some difficulty with accessing enumerations inside C+=
+ namespaces. I have attached a simple test program which binds C++ code co=
nsisting of one namespace 'nsa', one class 'Person', and three enumerations=
 'Country', 'Job', and 'Title', each at different scopes. The class and glo=
bal enumberation are both accessible as per the documentation but the other=
 two enumerations are not (see wxluanstest_prog.lua).
>=20
> There is currently no ability to use namespaces in the bindings and
> the enums can only go one level deep (MyClassName::MyEnumName).
>=20
> How would you envision it to work? If a %namespace tag was added to
> the binding generator I suppose that it should generate a table within
> the main table (the one the bindings are put into) for the next set of
> items and allow this for any depth level.
>=20
> This would be very awkward to try to put into the current
> implementation since instead of a flat list of classes with pointers
> to their member functions, we'd have to add another struct to hold the
> namespace name and then pointers to the classes, enums, etc in that
> namespace, and another level of the namespace struct, then the
> classes, a tree. But, thats not nearly as bad as what would have to
> happen to genwxbind.lua...
>=20
> However, I think there's an equally good and surely more simple
> solution. The only drawback is that you have to have an individual set
> of bindings for each namespace.
>=20
> You set the namespace in Lua and also in C++ like this in the "rules" fil=
e.
>=20
> hook_lua_namespace =3D "wxluanstest.nsa"
> hook_cpp_binding_post_includes =3D "namespace nsa"
> hook_cpp_binding_header_includes =3D "namespace nsa" -- or here
>=20
> Then the binding generator function wxLuaBinding::RegisterBinding
> would simply use the existing or create new "." separated tables. The
> code to do it would actually go at the top of
> wxLuaBinding::RegisterFunctions.
>=20
> Is there anything about this second way that wouldn't work? I think
> just setting the namespace in C++ should be enough to set the
> namespace level to anything for the C++ code to work or am I missing
> something.
>=20
> I do accept that if classes with the same name exist both in and out
> of a namespace that the binding generator code needs to call (I don't
> think it would unless your C++ headers had inline functions with them
> in it, but you could just prefix :: to get back to the root) there may
> be a problem. I think I would go out on a limb and say that that'd be
> a pretty sketchy design and wxLua can't cater to everything.
>=20
> Regards,
> John
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now>> http://get.splunk.com/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=

On 11/6/07, Darwin Slattery <dar...@ho...> wrote:
>
> Hello,
>
> I have been having some difficulty with accessing enumerations inside C++ namespaces. I have attached a simple test program which binds C++ code consisting of one namespace 'nsa', one class 'Person', and three enumerations 'Country', 'Job', and 'Title', each at different scopes. The class and global enumberation are both accessible as per the documentation but the other two enumerations are not (see wxluanstest_prog.lua).
There is currently no ability to use namespaces in the bindings and
the enums can only go one level deep (MyClassName::MyEnumName).
How would you envision it to work? If a %namespace tag was added to
the binding generator I suppose that it should generate a table within
the main table (the one the bindings are put into) for the next set of
items and allow this for any depth level.
This would be very awkward to try to put into the current
implementation since instead of a flat list of classes with pointers
to their member functions, we'd have to add another struct to hold the
namespace name and then pointers to the classes, enums, etc in that
namespace, and another level of the namespace struct, then the
classes, a tree. But, thats not nearly as bad as what would have to
happen to genwxbind.lua...
However, I think there's an equally good and surely more simple
solution. The only drawback is that you have to have an individual set
of bindings for each namespace.
You set the namespace in Lua and also in C++ like this in the "rules" file.
hook_lua_namespace = "wxluanstest.nsa"
hook_cpp_binding_post_includes = "namespace nsa"
hook_cpp_binding_header_includes = "namespace nsa" -- or here
Then the binding generator function wxLuaBinding::RegisterBinding
would simply use the existing or create new "." separated tables. The
code to do it would actually go at the top of
wxLuaBinding::RegisterFunctions.
Is there anything about this second way that wouldn't work? I think
just setting the namespace in C++ should be enough to set the
namespace level to anything for the C++ code to work or am I missing
something.
I do accept that if classes with the same name exist both in and out
of a namespace that the binding generator code needs to call (I don't
think it would unless your C++ headers had inline functions with them
in it, but you could just prefix :: to get back to the root) there may
be a problem. I think I would go out on a limb and say that that'd be
a pretty sketchy design and wxLua can't cater to everything.
Regards,
 John

Apologies for the second post - just fixing a small problem in the file tha=
t I originally attached.
Regards,
Darwin Slattery
_________________________________________________________________
100=92s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk=

Hello,
I have been having some difficulty with accessing enumerations inside C++ n=
amespaces. I have attached a simple test program which binds C++ code consi=
sting of one namespace 'nsa', one class 'Person', and three enumerations 'C=
ountry', 'Job', and 'Title', each at different scopes. The class and global=
 enumberation are both accessible as per the documentation but the other tw=
o enumerations are not (see wxluanstest_prog.lua).
I have included the binding code generated using wxLua 2.8.4.1 on Fedora Li=
nux, using the version of Lua supplied in that package, and wxWidgets 2.8.6=
 (GTK).
Any help would be much appreciated,
Darwin Slattery
_________________________________________________________________
Get free emoticon packs and customisation from Windows Live.=20
http://www.pimpmylive.co.uk=