11/12/05 Commit change

Kanma submitted some changes to the OgreNet project.

Here is what he said he did:

I did some minor changes to some interface files:
- SharedPtr, MeshPtr, MaterialPtr and SkeletonPtr are now correctly working (their use is transparent, they act like a Mesh, Material and Skeleton)
- Removed some warnings
- Probably some other details


Very cool... He says they're tested and stable... I haven't verified this yet, but I trust him.

Rastaman and I have been working on CEGUI data types and type mapping.

Last night we worked long in to the night to get the proper data types mapped... we got the InjectKeyDown and InjectKeyUp to work (those were using uint)... the only thing left to accomplish text input in to editboxes is to get the utf32 data type wrapped... InjectChar is required for editboxes to receive text, and that function takes an actual character value (utf32)... which isn't quite done yet... but I think that rastaman is sitting there working on it as I type this.

We're getting back on track guys!

Oh yeah, and I did something else... I deleted the old OgreNet.sln, then made a copy of OgreDotNet.sln and renamed it OgreNet.sln. As of this commit, both are equal. (I can't get the old OgreNet.sln deleted from CVS without submitting a ticket to get that done... so I figured, make it up to date, so either can be used.)

I'll continue to do this as time goes on... so either .sln file will work.

The new SLN files should have all of the no-longer-in-use "SWIGTYPE" files removed, so there's no more deleting tons of references from the solution before compiling.

ok I commited the changes for injectChar, and its working in DemoCEGUI.

Here's what i changed:
ogredotnet.linux.tar.gz //update to linux autotools scripts use autogen.sh not bootstrap
OgreNet/EventHandler.i //was not passing KeyChar just 'a'
OgreNet/OgreLog.i // was not showing up so i added
CeguiNet/CLSCompliancy.i //added typdef for udf and changed a few typemap(cstype) to Int64 insted of uint
DemoCEGUI/CEGUIApplication.cs //added call to injectChar

Verified earlier today that the InjectChar function is working.

If you're using VB to do it, you need to do the following:

GuiSystem.Instance.injectChar(Microsoft.VisualBasic.AscW(e.KeyChar))

For example:


Protected Sub KeyPressed(ByVal e As KeyEvent) Handles OEvents.KeyPressed
Try
If GUIHasFocus And Not A Then
GuiSystem.Instance.injectKeyDown(e.KeyCode)
GuiSystem.Instance.injectChar(Microsoft.VisualBasic.AscW(e.KeyChar))
End If
Catch ex As Exception
End Try
End Sub


OEvents is the Ogre events handler.
GUIHasFocus is a bool in my program for when the mouse is shown and such...
You have to inject both the keydown event AND the character for a statictext box to accept the character. This allows both control and character keys to work. InjectKeyDown is used for things like the arrow keys, backspace, shift-home to select the text, etc... otherwise, the characters you're typing are inserted in to a statictext by way of the injectChar function.

Has anyone tested Kanma's changes to MeshPtr? Is it possible to use manual meshes now?

When I have some spare time (very rare) I'll have a look myself if nobody else is using them.

Unfortunatly, it's still not possible at the moment.

What the patch does is the automagically wrapping of the Mesh's methods to the MeshPtr class. It's a standard feature of SWIG, I just had to gave the correct informations about it.

In C++, the operator->() of SharedPtr is overloaded to give a direct access to the pointee's methods (in our case for MeshPtr, a Mesh). It's transparent, you don't have to do myMeshPtr.get()->meshMethod();, but myMeshPtr->meshMethod();

Now it's the same thing in .Net, you can do: myMeshPtr.meshMethod().

There's still a way to retrieve the Mesh directly in case you need it for some reason: all the SharedPtr have a Get() method that return the pointee. There's also a method added by swig named __deref__() that does the same thing.

I also did some other modifications, for others SharedPtr and things like that, but I'm not done yet.

The manuel mesh creation is something I need too. At the moment, I've used an utility function written in C++ and wrapped with my framework, but it's a temporary solution, until OgreDotNet allows it directly.

I can't say if I can have a look at that soon. The main problem is the void pointers used to write datas into the buffers. The rest should be trivial. It should be easy to have solutions to create a mesh once and not modify it, but doing it efficiently for something like the water demo will be harder I suppose (not totally sure though...).

Kanma, thanks for the explanation. My manual meshes will not change very often so I'm not concerned about efficiency (yet). I'll post here if/when I make any progress.