The Closed bugs area seems to get no response so i figured i should post here again quickly to let you know the renderer.Fill bug is happening so it is not missed.

The suggested use of a null texture makes no difference.

The old thread was here:

scirra.com/forum/plugin-dev-bug-rendererfill_topic45082.html

I was using the previous version so i just re-downloaded and it's now working great without any crashes. Many thanks :D

By the way this other bug you seem to have set as closed is still happening -

http://www.scirra.com/forum/plugin-dev-bug-rendererfill_topic45082.html

Thanks for the info, i tried doing as you say however exactly the same thing happens again when i update the code.

IDEInstance.prototype.Draw = function(renderer)

{

    renderer.SetTexture(null);

    renderer.Fill(this.instance.GetBoundingQuad(), cr.RGB(100, 100, 255)) // Currently has a bug

}

I originally did not use the texture flag as i found it automatically opened the image editor but i tested adding that and it unfortunately it did not make much difference either.

I have had the fill working from the start but it's always inheriting the Sprite objects image whatever i try. I am guessing i have done something wrong still, do you have a simple code snippet if possible? thanks

I am not sure if the previous post means a upcoming build but i did some testing with R61 and it no longer happens for Sprite, however crashes happen for basically all other objects. <img src="smileys/smiley3.gif" border="0" align="middle" />

The general method for a crash is:

Add 2 text objects, Select Text2 in the layout and press the Delete key. Text2 is still in the Object types folder (shouldn't be in my opinion), select it and press Delete key and you get a crash. The same thing happens with Tiled Background and the other visual plugins.

In fact the delete system seems buggy in general and does it with hidden objects also. If you add 2 Arrays click Array2 in the Objects tab and press delete it will crash the program. If you add a either a WebStorage, keyboard, Mouse, Browser etc then delete it from the Object types folder the program crashes.

I am starting to think using this history feature rather than a true delete is maybe just causing the program more problems than it's worth. I don't fully get the need to have a sprite object with no instances either as couldn't you just have a hidden sprite?

If it's going to remain it would be nice if there was a way to set a option somewhere to bypass it and just directly delete objects (Remove from the Object types folder also) when using the Delete key shortcut on the Layouts object. If the crashes/bugs get sorted it would be less of a problem but hopefully that could be possible also.

Ok well it's not something i need asap, but i was planning on using it with a behavior so it is definitely something i would use yes.

I had also posted in the general section while you were away with a few other plugin/behavior development requests mainly aimed at property organization. These are also not things i need right away however as a coder that would definitely use these features if they could ever be added that would be very useful to me. The post was here -

http://www.scirra.com/forum/plugin-dev-request-edittime-properties_topic45084.html

Many thanks

It could also be quite useful to be able to set a input as enabled/disabled or shown/hidden. I was thinking this way you could use many controls but just show any needed for a certain mode using a ept_combo for example.

Of course through the coding part it would still allow you to get the values even if they were later hidden/disable as these would be needed if the mode changed at runtime.

I think this could be another great way to organize plugin and behavior properties. Thanks :)

Not currently due to that crash but i had tested it with plugins and was working great (The SDK is really great by the way) so i was wanting to use it with behaviors when it is available. :)

I had guessed that it was probably just not yet implemented as it was not listed in the SDK docs for behaviors, however i figured i should report this just in case as it caused a crash. Many thanks

Thanks Ashley, i think with the bug fixed, window focus and the prompt this will be a lot nicer now. :)

Due to the fact it works correctly with a right click delete on the Object types folder but leaves the objects if you press the delete key just makes it seem like a bug.

I also don't see why you would want objects to remain still if you press the delete key shortcut on them and it's the last instance. It's sort of making using the program annoying for me because i am so used to using keyboard shortcuts and if i delete something i don't really want to do it multiple times.

The fact it triggers a crash when the last instance of a sprite is deleted suggests there is history stored also or it doesn't correctly delete for the project. So to me it seems like a bug but if it's intended i don't really see the reason why to be honest.

It seems rather than a bug it's some sort of object history thing then but does the object history get stored with the project? If yes it would be nice to have a clear history button or a way to disable the feature as i doubt i would use it much.

Also i noticed if you delete with right click from the folder listings there is a confirm dialog, so there would be a additional bug in that the delete key shortcut does not also trigger a dialog.

I noticed if you press the Delete key on a object it will delete it and remove it from the objects list however it remains in the Object types folder in the Projects dialog.

After objects have been deleted it can also create a crash on exiting the program that says "Object has no animations" which i guess is happening after deleting a sprite object that it can no longer find.

I was thinking recently that for edittime properties there is 2 types missing that i would find quite useful:

The first thing is paired/grouped values like you already have with the Common properties for Position and Size. It would be nice to have these available to use as a with regular plugin and behavior properties.

Then the other thing would be a separator line. Each item is already separated by a thin line so maybe it could just make that line chosen color and also slightly thicker, maybe with a optional title text. This would be helpful if a plugin or behavior was slightly more advanced and you wanted to organize the properties into a few groups.

I think these would be quite useful as new ept_ types, hopefully you will like these suggestions also. Many thanks :)