|
Before writing a custom inspector to add some details related to source files (specifically .cs, but could be anything), I thought it would be good to create a simple override inspector as a starting point. How hard could it be, right? However, the following does not deliver the expected results - that of the default inspector behavior. What's wrong/missing? thanks in advance.
(comments are locked)
|
|
To draw the default inspector you should not call the base's method, instead you should. call DrawDefaultInspector() Take a look at scripting reference page for Editor class to learn more. Also you are trying to write insepctors for MonoScript which is an Editor type and not a runtime one and Inspectors can only be written for components and not other data types. So your class should be either a component or be a children of it (direct or indirect). that has the same effect and does not show the default behavior. my example used base.OnInspectorGUI() to show that the default behavior was NOT being used. I've edited the question to clarify.
Aug 27 '12 at 06:34 PM
gjf
Do you expect anything else? This functionality is useful when you are writing a custom inspector for a component. MonoScript is a type only available in Editor and i don't think you can do this with it. Unfrotunately Inheritance is not supported for this so you can not do it for MonoBehavrious as well. i've written successfully multiple custom inspectors. The only flaw was that the inspector of classes did not work when you were using them in inspectors of other classes as public variables which is being corrected in unity 4.
Aug 27 '12 at 07:53 PM
Ashkan_gc
actually, yes. i'd hope that by calling the default method, the original functionality would exist. i've written a dozen or so custom inspectors, so it's not like i'm a total noob ;) i'm trying to add relevant information to certain scripts - be it editor based global variables for security credentials (which shouldn't be stored in any script) or displaying additional info such as the number of references to a script, etc. i can think of quite a few use cases, but without being able to call the default behavior, it's 'breaking' the editor. i don't want to write the entire inspector when all i need is to display some custom info first... i ended up using the editor preferences to store the credentials via a custom editor, but it would have been useful to see it tied to any script that needs it. i realize that monoscripts are special and could use some reflection or refer to the original assembly, etc. but didn't want to reinvent something that should be relatively straightforward.
Aug 27 '12 at 09:05 PM
gjf
The bad thing is that scripts are treated like other assets in this regard. you know, unity thinks you should show those information about MonScript in Asset Preview of the script like dimentioned which are being shown for textures or vertex count which is being shown for meshes in asset previews. I don't know if it can be useful to you are not but i fully agree that scripts should have a general hookable inspector. hopefully in Unity4 which you can create custom inspectors for classes which anywhere can be used, we'll have the ability to write something for MonoBehaviour and use it in all scripts. It's the point of the new feature after all. see keynote of unite12 (the Nicholas part) for more info.
Aug 28 '12 at 05:54 AM
Ashkan_gc
unity4 behaves the same as earlier versions - i'm running beta7. nicholas' keynote didn't mention anything specifically about my problem, which i don't think will be resolved if i can't find a way to replicate the default behavior. maybe i'll need to play with ilspy a bit...
Aug 28 '12 at 01:19 PM
gjf
(comments are locked)
|
|
DrawDefaultInspector is the default inspector for MonoBehaviour scripts. All other built-in types have a specialized custom inspector or are handled directly by the inspector window. I suggest to download ILSpy (which can also decompile to C#) and take a look into the UnityEditor.dll. There you will find all built-in stuff. Most of the built-in classes are "internal", so you can't derive your own classes from them, but you can copy the original source and create your own custom inspector. What you are talking about is decompilation and might violate the rules of Unity so be careful of what you are saying, however, educationwise it's really useful.
Aug 27 '12 at 07:51 PM
Ashkan_gc
Reflecting managed code is actually a feature of CIL / .NET. Also there are other reflector applications out there. Sure respecting copyright has nothing to do with the abillity to view the source. I've even heard that MonoDevelop is also capable of reflecting dlls. I don't use MonoDevelop so i can't tell ;) In case of managed code, decompilation is very different from decompiling native code. When you browse the code as IL it isn't even "decompiled", it's just translated bytecode.
Aug 27 '12 at 09:21 PM
Bunny83
I agree with your definition about decompilation and you are right, if managed code is not obfuscated so they made it visible and said, you can take a look np. copying is another thing as you said. I just wanted to avoid problems. Regarding reflection, yes it's allowed in the sense that you are allowed to dynamically at runtime or statically reflect on types and see what fields and methods are in them and use them. mono even has a tool called ceicel or something with a similar spelling which allows you to reflect and also add/modify IL code of the assembly and unity even have a session on it in unite11. When Microsoft itself has one of these reflection tools so they are ok but reflection is different from decompilation of translated IL code to C#.
Aug 28 '12 at 05:51 AM
Ashkan_gc
(comments are locked)
|
