wxWidgets (again)

[Anonymous]

Hi Andrew,
long time no talk.
I would like to bring in the wxWidgets talk again. Since my very first attempt to create a wxWidgets wrapper library for Suneido, (let’s be gentle and say it was a learning process) the situation has changed a bit. With the new wxWidgets 2.9.x series respective the upcoming 3.0 release, documentation is done now by Doxygen.
In fact we can use Doxygen’s XML output to create wxWidgets Suneido bindings. No need to use SWIG or what the heck. It has been done successfully for PHP and In PHP.
(link at the end of doc.)

I would like to invest some time. I have to say that a pure Suneido_wxWidgets.DLL version is IMO impossible. Means we have to a add a couple of builtin functions. prime.

To give you an idea, nevertheless out of date. due to doxygen xml.
http://wxphp.org/docs/development/intro
Last info.
http://wxphp.org/wxphp/blog/commit-of-new-version

What do you think ?

Bjoern Lietz-Spendig

[amckinlay]

Hi Bjoern,

Good to hear from you. I am open to doing something with wxwidgets. Maybe it would even give us a GUI option for the Java version of Suneido.

I don’t have a lot of time for this but I will try to help where I can. I can certainly answer questions. And if we need a few built-in functions added to the Suneido exe (i.e. in the C++ code) I can try to help with this.

One question is whether it would be possible to make it compatible with existing application code. e.g. could we make compatible versions of ButtonControl and FieldControl that call wxwidgets. If not, it would be a big job to change all the application ui code.

andrew

[Anonymous]

Hi Andrew, just to give you an idea about the Suneido/wxWidgets binding generation.

class wxStringMap
{
public:
wxStringMap();
virtual ~wxStringMap();
bool HasValueFor(const wxString& key) const;
const wxString& ValueFor(const wxString& key) const;
};

The generated wrapper wxsuneido.dll

extern “C” __declspec(dllexport) wxStringMap* wxStringMap_CTor() // CONSTRUCTOR
{
return new wxStringMap();
}
extern “C” __declspec(dllexport) void wxStringMap_DTor(wxStringMap* self) // DESTUCTOR
{
delete self;
}
extern “C” __declspec(dllexport) bool wxStringMap_HasValueFor(wxStringMap* self, const char* key)
{
return self->HasValueFor(key);
}
extern “C” __declspec(dllexport) const wxString* ValueFor(wxStringMap* self, const char* key)
{
return &(self->ValueFor(key));
}

And finally the GENERATED suneido class (a fraction)
wxStringMap = class
{
New()
{
,classptr = dll int* wxsuneido:wxStringMapCTor()
}

HasValueFor(key)
{
return dll bool wxsuneido:wxStringMap_HasValueFor(classptr, key)
}
ValueFor(key)
{
}
}

A few question and suggestions.

What about the Destructor ?

We should start with wxWiodgets 2.93 to avoid UNICODE / NON UNICODE problems. Does Suneido support Unicode strings ?

I think it would make sense to have a generic IntPtr 32/64 bit agnostic!

So I was wrong. We will have a DLL (wxSuneido.DLL) and wrapped classes)
Keep in mind that the gemeration of wxsuneido.dll as well as the suneido wrapper classes are generated. So probably so Suneido for wxWidgets is close than one mifgt think !

Next message will contain some thoughts about event-handling etc.

Would be nice to get some feedback .
Bjoern

[amckinlay]

Sounds reasonable.

The destructor could be handled by using a standard name like “destroy”.

Suneido dates back to when “long” meant 32 bits 🙂 Now it would make more sense to have int = 32 bits and long = 64 bits, with a separate type for pointers.

One issue to watch out for is garbage collection. If the dll is allocating objects in Suneido’s heap, then you need to make sure there is a reference to them so they don’t get garbage collected. The rules about allocation in dll’s are confusing, and in this case there are multiple dll’s.

[Anonymous]

Hi Andrew,
point taken. (Allocation) So let’s start again from this wxWidget class. I’ll skip the C wrapper.

//wxWidgets C++

class wxStringMap

{

public: wxStringMap();

virtual ~wxStringMap();

bool HasValueFor(const wxString& key) const;

const wxString& ValueFor(const wxString& key) const;

};

Our Suneido class could look like :

wxStringMap = class

{

isDisposable:  true;

classptr:  0;



New()

{

,classptr = dll long* wxsuneido:wxStringMap_CTor()

}



//NON Thread save, we need a _mutex_lock_ here

Dispose()

{

if (.isDisposable)

{

IsDisposable = false;

// Call class destructor

dll void wxsuneido:wxStringMap_DTor( .classptr )

}

.isDisposible = true;

}



HasValueFor( key )

{

//autogenerated    ??     Assert( key.isString() ) ]

return dll bool wxsuneido:wxStringMap_HasValueFor( classptr,  key.towxString())

}



///  etc.

}

---

Now you see that I have used Dispose (DOTNET style) instead of Destroy.
Slightly Off topic
Maybe we can add a small convenience (syntax sugar) feature to Suneido :
alias Dispose Dwstroy;
//or
alias long* wxObjPtr;

For me this is bread and butter.
// D code;
class ArrayList( T ) { }
alias ArrayList!( int ) IntegerList;
IntegerList il = new IntegerList();
I know that you like that!!

---

OKay . For all wxWidgets constants, enums, and global variables we can create Suneido code. Right now.
Same is also valid for the C Function wrapper DLL .F.I.
extern “C” __declspec(dllexport) bool wxStringMap_HasValueFor(wxStringMap* self, const char* key)

What needs some attention is the Suneido class generation..
Open Questions are event-handling,…. Suneido’s layout manager vs. wxWidgets Layout manager. .keeping the current Suneido “Business objects” as far as possible in sync with wxwidgets. …..
Quit some stuff. I would prefer to discuss details via email (if you like ) makes it a bit easier for me.
email starts with amckinlay ?
Bjoern
ps. till next Sunday I have to work on a commercial project, so icase that my feedback takes awhile don’t worry.

[amckinlay]

You can reach me via mckinlay@suneido.com

[Author]

Posts