Add pre-filled dropdowns to ACEs

Just a thought - wouldn't it make sense to turn the variable fields in ACEs into combo-boxes, pre-filled with some of the standard things we would put in them.

For example, the "Control is Down?" event has a text field to put in the control to check for, with a blank set of quotes to tell you to enter a string. Now, there may be occasions when I may want to put in an expression of some kind (I don't know if the would work because I haven't tried it), but 99% of the time I will want to put in one of the standard controls found in the Application properties.

Of course, I can't always remember exactly how they are written, so I usually go through this process: open up the new event window, realise I can't remember the variable name, close it, click on the layout tab, click on a blank area of the layout to open up the layout properties, click on the Application properties link, scroll down to the controls, commit "Jump" to memory, then go all the way back to the new event window and enter the control name.

Since the controls will no doubt be accessible somewhere in the code, why not just make it a combo-box and make everyone's work easier? The same is true for large number of the variable fields in ACEs, like references to image points, sprites, objects, resources.

I really think this could cut down on errors and speed up development time considerably.

Yeah, it'd be nice to have this. However, you know you can get to application properties just by selecting the application header in the project bar, right?

Well, I didn't, but I do now. It took me a while to figure out exactly what you meant. I had assumed there was an easier way to get there.

Anyway, that lengthy description was mainly just to make my point- that it would be awesome to have all those potential variables already available to us in a combo-box. I've been thinking it from the moment I started playing with this software- I've even spent time looking for it, because it seemed such a natural part of the software that I assumed I just hadn't found it yet!

Yeah, I want it too, for everything from animations to layer names. It saves you having to remember and prevents typos causing bugs as well (if you mis-spell an animation name for example). I'm not sure how easy it is to do in the current IDE though. It might need to wait for the rewrite. Rich can answer on that maybe.

Lets take the simple example of animations. The problem with having a dropdown is if you have the object as a family, then the animations could be anything. Also, in the future we want to add the ability to change with animation 'package' a sprite uses. So just like you can have gradients with separate colours, you could have a single object like 'background tile' have different animations. So having a combo box of animation names isn't really possible

The best solution I can think of right now is having a combo box somewhere which fills up with the name of every single animation name used in the application...or in the expression wizard you could select an object and there'd be a combo box saying 'animation names' which you select and it add in the string for it.

Controls could be done...they are per application

Layer names though is a bit of a problem because you dont know which layout an event sheet could be refering to...so the only solution is to list every layer in every layout of the application....

Anyway it's something that requires some though and time...and right now is not the time coz i'm drinking woodstock

It's incredibly hard to do this because as David says, event sheets aren't linked to layouts. You'd have to have every layer name in the application for layer parameters, for example.

But there are at least some things, like controls, that could benefit from this. For example, in my tank tracks example I used the spawn command, which can spawn to an image point - surely Construct knows that the Tank object has two image points called 'lTrack' and 'rTrack'?

The problem is that, because everything is modal, and in some cases further modality within other modes, the benefit of the IDE over pure programming is lost somewhat, as we still need to remember exact spelling, cases, etc. of the objects and variables we are using. It's not a good thing if you have to cancel the current mode and go back to the mode where the information is held, is it?

Perhaps we could try listing which items can use some form of intellisense with relative ease. Also, the advantage of using a combobox for this is that people can still type it in directly if they want to. If we do populate the list with all layer names within the .cap (merging duplicates), they can pick from that list or write their own (before adding it to a layout).

I love how Rich is able to rephrase what took me 14 lines to say, into a mere 3 lines and make it make more sense