Well, the fix was indeed simple. I hadn't had the opportunity to work on it for a few days, but when I got to it this morning it took all of about five minutes to put it in. It could actually probably be trimmed down at this point, as I think it may have gotten slightly redundant. Ultimately, it works now, though. Everything else is gravy.

Here's the properly working color picker boxes for anyone interested. Thanks again to Newt, Tulamide, Tokinsom, Scidave, and Sully for help in this little endeavor. The solution in the colorpicker CAP can now be implemented into the profiler.

The profiler's not worth posting yet, but if it develops into a more generally useful tool, it may get posted in the future. :]

http://largeangryrobot.webs.com/colorpickerfix2.cap

Construct Classic r1

Thank you very much, Newt. That has entirely solved both the "Cancel" problem and the single cycle delay when using the "OK" condition.

It has, however, created a different issue, wherein picking the color in the second box will also change the color in the first box. I can see exactly why. The condition of the Toggle private variable from the other is still true when the second box is also color picked, so it recolors both.

That one I can probably smash my head into until the solution clicks. It's always facepalmingly simple when I figure it out. Makes me feel like such a dunce sometimes.

Again, thank you for introducing me to the function there. It's got things on the right track! For now, it's late, so I'll putter with it tomorrow.

I feel like I've committed some kind of sin for quadruple posting, but I still haven't figured out the color box matter.

I tried using the "On Colour Dialog OK" event condition, but it produces another strange result. Particularly that it has a full one event cycle delay before applying the color to the box. So, the first time you hit OK it applies a blackish color to the box, even if you selected red. If you repeat the action, it would apply red to the box, even if you picked orange.

With the help of the other posters, the search function, and the wiki, and some thoughtful workarounds most problems thusfar have been conquered. I just can't seem to trample the Colour Dialog problem, though. :[

Hello again!

After many days, things are looking good. The profiler is in a functional condition, although it still lacks things like failsafes against common user errors and has a few quirks left to iron out. Still, it does the most basic things that will allow us to start using it and storing character data. I'm having a friend put it through the ringer, since another pair of eyes always finds something I've overlooked.

One such case was brought to my attention. I'm using the Box Object to allow the display of a particular color, selected by the user. The color is set by means of the Windows Color Picker via the Common Dialog Object.

The problem is that if you cancel out of picking a color, instead of leaving the color in the Box in question alone, it will set it to the previously selected color.

Rather than include the entire profiler (which is still a mess and needs intense optimization and reworking in many areas), I have distilled the problem down to a tiny .CAP with just a few events. It allows accurate reproduction of the error. If anyone can figure this one out, I'd be much obliged. As it stands, a simple misclick could cause loss of your selected color, and that's no good.

CAP File:

http://largeangryrobot.webs.com/ColorBoxes.cap

That is very unfortunate. I hope you find something that works for you in short order!

It's a tricky time to buy a new laptop with a decent IGP, though. AMD's Llano is fast approaching.

Edit: Using the debugger informs me that event 5 is attempting to add a string to an integer. Looking into it.

Edit 2: Solved the Integer/String conflict. Apparently only part of the problem. I'll look into it more tomorrow...for now, bed.

Edit 3: Fresh morning! Fresh mind! It appears to be working properly now. After fixing the Integer/String conflict, it ended up being a conditional fallacy in the blocks and a mistyped variable. I can now save new characters and it will properly seek out and overwrite existing characters with new information. Thank you for your patience!

Next up, the delete function. That should be delightful.

Also, the debugger in this is great. It's so clear in listing everything that you're looking at. No more archaic C++ debuggers. <3

Again, I appreciate all the ideas. For now, I think I will go with the simple and brutish approach to get it up and running for my friend and I. As we'll be using it for some time, I do plan on refining it both visually and functionally, so it will likely go through some under-the-hood revisions (likely in the veins you've both suggested) to make it smoother and easier to handle.

Ahh, clever work around with a box object! Thank you for this, it saves me some questions later. :]

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.

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.

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!

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.

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.