Roland

Yes .. thats the word.

Could not agree more

Yes. I agree on that

Hmmm.. Wish I could write in Swedish. What I mean is when you checks the state of an object as in entity.IsVisible() ; Here you don't get a value, you get an answer on a question about the object state.

Yes Rick. Absolutely correct. That was how I wanted to design LEO from start, but I was voted down on that one. Maybe we could get it the proper way in LE3 And -> is a beautiful as .

How is Position and Rotation declared above ?

To conclude this long discussion. Here is my opinion. 1 All members should be either private or protected 2 Retrieving a member should be done using a GetXXXX() const method 3 Setting a member should be done using a SetXXXX( const& value ) method 4 Queering an object state should be done by calling a bool IsXXXX() const method 5 Destructors should ALWAYS be virtual. 6 Public members should NEVER be allowed.

No of course not. My mistake. GetRotation is const. Must be tired.

Same goes for LEO. cube.GetRotation().X = 10 ;

My approach is that either you go with oop-rules or you don't. You cant have if kind of half-oop and go the struct public way in some places and not in other places. Get,Set is simple to understand. Its fast as it will be inline code when optimized by the compiler Its a question about be consistent in you coding. If you are making members public, well whats the idea of using classes at all. Then you could use struct's instead. About adding extra methods like suggested. That may be OK even though I think thats not needed. If anyone want those I would be easy to make an own version with those methods that inherits the original.

The two last suggestion can seem handy, but they goes against all oop rules. I would not recommend those. Data protection (or hiding) is a very important part of good oop programming.

AO ... wow what a difference. Great work

Cant wait to dive into it :P

My personal preference is to go the LEO way, of course Set to set things Get to get things Create to create things Always the same. You never have to wonder ... Edit: Oh.. and one more thing while I'm at it GetXXXX should always be const method All arguments that is input-only should also be const

Yes thats true. Using properties you would have to go this way entity.Position = new Vec3( 1,2,3 ) ; // C# entity.SetPosition( Vec3( 1, 2, 3 ) ) ; // C++ Edit: In C++ you could have Position Vec3 as a public and then use a Vec3= operator Then you would have almost same as in C# entity.Position = Vec3( 1,2,3 ) ; // C++

No. The property approach works just like an assignment. You can compare the set thing with the operator=( some value ) in C++ For more than one argument you have to go with a normal Method. Edit: In LEO I implemented some kind of set/get approach Everything that assigns something has a SetXXXX method and everything that queries a value has a GetXXXX method

I'm no C# expert but this is how it works A property can be declared and then when used it has a get and a set method internally. An example public class myClass { private int myval = 0 ; public int MyValue { get { return myval ; } set { myval = value ; } } } the class can then be used like this myClass c = new myClass ; c.MyValue = 10 ; // the internal set will be called and assign 10 to myval int x = c.MyValue ; // the internal get will be called and it returns the myval You can omit to write the internal set method c.MyValue = 10 ; // Causes a compiler error as the MyValue now is ReadOnly (it has no set method) Of course you can the have more code inside the internal get and set to do more things as range checking or whatever you decide

Maybe some did, but memory leaks are not always easy to catch, so that may be the reason you have not got any answer. Usually the community gives quick answers. I cant help you either as I do all my stuff in C++ only. Hopefully someone will help though. At least you have now seen that someone read your post

Very interesting storyline, Lumooja. Anushar ... Annunaki ... could be

Yes DaDonik you are right. I have now tested and they are not returning the correct values. I found this when setting the max length of my Editboxes in my Cells C++ GUI. TextWidth return incorrect values.

This looks just great. Then only thing I has to add is that it would be just perfect if keyword links was generated. That means that if in the documentation of a function or a class, another function or class is mentioned, this would be a linked to that other class documentation page.

Yes. Looks very nice and Pro

Yes. They are only returning values. What I was thinking of that you could use those values to resize the surroundings, like a text field height and width.

Suggestion: You could use FontHeight and TextWidth functions to dynamically resize things depending on current font

I'm in no position of influence what is going to be done with LE in the future. I was just giving my personal opinion and thats an opinion coming from a C++ developer. I might be wise or not. In fact I don't care what Josh use to get the thing going as long as it does and I can use it from C++. But if someone ask me I would prefer the C++ solution. I bought BMax and Blide to get started with that, but after a while i found that although it works perfectly I made better results with C++. Why? Not because there is something wrong with BMax. The reason is that I'm used to C++ since dirt was invented and makes things faster in C++. So I guess its a question of ones personal background. And I still think using C++ makes the engine less dependent on non-Leadwerks resources. But that could be said about using OpenGL also, so in the end its up to what Josh find best to work with. I can live with any solution as long as the engine is good and has a C++ API. The question is if it should be Leadwerks task to promote it. As all knows I vote for a C++ engine with Bmax API supported. C# and other language API by the community as before