Add pre-filled dropdowns to ACEs

New releases and general discussions.

Post » Mon Feb 16, 2009 10:00 pm

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.
B
2
S
2
G
3
Posts: 105
Reputation: 1,510

Post » Mon Feb 16, 2009 10:33 pm

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?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Mon Feb 16, 2009 11:10 pm

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!
B
2
S
2
G
3
Posts: 105
Reputation: 1,510

Post » Tue Feb 17, 2009 12:32 am

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Sat Feb 21, 2009 2:35 pm

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
B
4
S
2
G
5
Posts: 641
Reputation: 3,011

Post » Sun Feb 22, 2009 11:44 am

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.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

Post » Sun Feb 22, 2009 10:38 pm

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).
B
2
S
2
G
3
Posts: 105
Reputation: 1,510

Post » Mon Feb 23, 2009 5:13 am

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 :|
B
4
S
2
G
5
Posts: 641
Reputation: 3,011


Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests