[Retitled] Amalgam of vaguely related questions.

For questions about using Classic.

Post » Wed Apr 13, 2011 7:34 pm

[color=#400000:2oojqu2u]EDIT: Rather than make a whole new thread, it seemed like a better idea to keep all my silly little questions to one thread as they come. No point in me clogging up the forum.[/color:2oojqu2u]
_______________________________________________
Hello. First time poster, so be gentle. :]

I've been looking at Construct for a while, and have been tinkering with it for a few days. Thusfar, I've found it more enjoyable than MMF1.5 (which had its merits, but Construct has some indescribable facets I prefer already), but there's one thing that I just stumbled on while teaching myself how to make use of Arrays, Edit Boxes, and the Text Object.

You see, when I make a Text Object in the Layout Editor, it misrepresents the font size. I'm guessing by a factor of about 2 or so. While I can eyeball it to compensate as I putter with my little project, it's just kind of this little gremlin that nags at me.

Here's an example of what I mean, with the layout on the left and the runtime preview on the right:


As you can see, the font is a proper Size 10 in the Runtime, but significantly smaller in the editor. I've tried this on two different PCs (one cruddy old XP laptop, one shiny new W7 desktop) and the results are the same, even on a fresh project. All I can tell so far is that it seems possibly tied to the choice of Application or DirectX runtime. Picking Application shows the reduced size font in the Editor, and the normal size in the runtime preview. Picking DirectX shows reduced size in both the editor and the runtime.

Is there something I can do? Should I just work around this, or is there a tweak/setting that I've missed in order to get the editor to show the proper font size with the Text Object? I can provide a CAP if needed, but it seems to happen on entirely different PCs, whether I use a new file or my current project file.
B
2
G
1
Posts: 14
Reputation: 478

Post » Wed Apr 13, 2011 7:46 pm

Text objects change size in the layout editor when you zoom in or out. Maybe that's what's happening here? It's been fixed in C2, btw.
Image
B
225
S
27
G
13
Posts: 1,774
Reputation: 18,024

Post » Wed Apr 13, 2011 7:57 pm

Hm. I see what you mean about the Zoom. It appears to be controlled by Ctrl+Wheel Up/Down (standard). That said, I'm working at 100% size, and interestingly the text remains at the same size on the screen despite what the Zoom level is at -- it's the same pixel size on my screen if I blow it up to 200% or shrink to 50%.

Further tinkering suggests it may have to do with specific fonts. Arial and TNR demonstrate the misrepresented size, but Courier does not (perhaps because it's a system font?).

Edit: MS Sans Serif also appears to display normal sizes. Hrm...

Edit 2: Okay, rather than Courier and MSSS displaying normal sizes, they're displaying the reduced size (again, a font size reduction of 2) in both the editor/runtime. Well, at least MSSS is a relatively readable font. I think I can work with that, need be.
B
2
G
1
Posts: 14
Reputation: 478

Post » Wed Apr 13, 2011 8:06 pm

The editor isn't always entirely intuitive at times, so you might just have to work around this. I'm not an expert of course, so a solution might exist somewhere out there.

Welcome to Construct, by the way. :)
B
20
S
9
G
6
Posts: 607
Reputation: 6,112

Post » Wed Apr 13, 2011 8:11 pm

Thanks for the welcome. This program is bounds ahead of ol' MMF1.5 in terms of both function and the fact that it doesn't max out your CPU cycles when a simple text application is at idle. :]

I can work with MS Sans Serif since it's at least consistent. Courier is a bit unappealing to the eye, but MSSS is fine.
B
2
G
1
Posts: 14
Reputation: 478

Post » Thu Apr 14, 2011 1:13 am

Right, so. Some hours of tinkering and reading later, I'm getting to learn things. For one, I've opted to go with the DX runtime for the application, as I can use it to make quickly swappable color blocks, which appears to not be an option for Application runtime (understandable). The DX runtime also lacks the problems with misrepresented font sizes, making layout setup much easier.

There's now a new question. Is there a way to move the text cursor (rather than the entire mouse cursor) between the edit boxes? Let's say I have 3 EditBox objects, which we'll call Edit01, Edit02, and Edit 03. Normally, I would Tab (which I can read for with the Keyboard & Mouse object) and then the cursor would move from Edit01 to Edit02. If this can be done, then presumably reading for the combination of Shift+Tab can make it go in reverse, including Edit01 to Edit03.

I'm not seeing any particular condition to move the text cursor between edit boxes, and I've not seen it mentioned in my searches on the forum (though there was a handy post on rigging colorable edit boxes using multiple objects). Possible? Impossible? Again, not a dealbreaker, just a matter of UI refinement.
B
2
G
1
Posts: 14
Reputation: 478

Post » Thu Apr 14, 2011 1:29 am

The edit box has two actions called "Focus on" and "Focus off", they set and clear the focus (set the text cursor to the specified edit box, or clear it)

One tip: Often objects are not documented very well. A way to at least get a hint if some functionality exists, is to right-click the object in the object list (while the layout editor is active) and select "Object information". This lists all ACE of the object and helps sometimes.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Thu Apr 14, 2011 3:18 pm

Thanks for the heads up. After checking out the Object Information window, there really is a heap of undocumented features in there for some of the objects!

The Focus on/off is doing the trick, and I can now put the focus onto any given EditBox. An If/Else block with a hidden variable to keep track of which edit box is on seems like a reasonable approach. While working on that, I hit another snafu. I can't seem to find any condition that detects whether an edit box has focus, so I could lose track of which one has it.

Then again, maybe I can just keep track of it by detecting when the object is clicked with the mouse! I think that's doable, since there are conditions for objects being clicked, through the KB&M object.

Ironically, after all this talk of tabbing, it seems that the edit boxes inherently have command over the tab key to make an indent that can't be overridden. It still moves between boxes, but puts indents in on the previous box. :lol:

Really, this is a job best suited for a simple spreadsheet, but it seemed like a good way to learn about some of the basics in Construct, so I will press on anyway. Thank you again for the assistance. :]

EDIT: On further thought, I can just reassign the tab function to a different key. Probably one of the Function # keys. Construct certainly does lend itself to clever solutions!
B
2
G
1
Posts: 14
Reputation: 478

Post » Thu Apr 14, 2011 11:17 pm

I read your tutorial on Arrays, Tulamide. That was very informative, and perhaps I'll look into whether I can/should use hash tables as things go on. :]

So, to end the guessing games, what I'm putting together is a (very Spartan looking) character profiler. Name, age, height, all the details. Neatly storable in an array.

My next question is more a matter of the "proper" way to do something. In this case, array maintenance. There is a possibility that characters would be deleted from the array, which would leave a host of blank cells. Keeping the array from becoming bloated with blank chunks means that there will have to be some form of maintenance since it can't always be assumed that the deleted character will be the last one in the Array.

The format is X is a column that contains all the relevant information for a single character, and Y is each item of info (currently at 16, but it'll get larger).

As far as maintenance goes, I can think of a few ways.
A) When a character is deleted, set all their column values to 0/Empty/Null, what have you. To minimize wasted space, when saving a new character the application could search for empty columns to dump said new character into. This could still result in multiple unused columns if more are deleted than added, and would still require some kind of maintenance function. It doesn't really seem like a good idea.

B) When a character is deleted from the list, the maintenance function automatically begins to copy over the data from any columns that follow to the empty one, in a loop. When the final column is the empty one, it truncates by reducing the array size by a factor of one. This ensure that no matter how many characters you delete in succession, there won't be any empty columns. It seems like the better solution for tidiness.

My concern with approach (B) is the time it will take. I expect the array's final size to be something like 50x35x1, but it could be larger still. It's not monumental in size, but what kind of processing time are we looking at if the character in column 2 gets deleted, meaning that the remaining 48 columns need to be shifted over? I'm sure part of that will have to do with the efficiency of the loop, but I'm still curious. My (limited and decrepitly rusty) C++ experience from college tells me that I should always keep on top of maintenance, as in approach B.
B
2
G
1
Posts: 14
Reputation: 478

Post » Fri Apr 15, 2011 12:48 am

You shouldn't notice a performance impact with a 50x35 array and leaving entries blank. However, one way to do it would be to have a hashtable hold your characters with the value an index into the array. That way you would always get really quick access to your array info without any searching or sorting. When you delete a character, the hashtable entry would be deleted (the hashtable is an automatically sized list) and the index could go into a deleted index hashtable for use later if you add a character back.
B
8
S
3
G
7
Posts: 835
Reputation: 5,313

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 2 guests