Problem Description

When I export to mac a project that has a text with height larger than +8000, it just shows a black box. This doesn't happen on Windows or during testing in Chrome.

Attach a Capx

https://www.dropbox.com/s/umqbshsx7mc0j ... RKING.capx

Description of Capx

Just shows a project with a textbox bigger than around 8000. When exported to Node-Webkit for Mac, it shows only a black box where the text should be.

Note: I had the same problem with 8000+ height in mac, but then I used minimise, and it managed to overcome that limit, and 8000 + started to be the new limit.

Steps to Reproduce Bug

• Open capx
• Export to node webkit
• Open with OSX

Observed Result

Black box instead of text

Expected Result

.app exported project to show the text, not a black box

Affected Browsers

• Chrome: (NO)
• OSX: (YES)
• Windows: (NO)

Operating System and Service Pack

Windows 7 SP3

Construct 2 Version ID

Latest

EDIT: Found that it doesn't work for +6000 too

Found another post that solves my problem and probably yours OP

Just use BatChmod.app it's an app to change permissions.

If not that, then just don't use parralels to drag and drop, and enter bootcamp and transfer the file via usb.

It might also work if you send it to your self by email, but inside parallels windows , not from the mac.

During the transfer from Parallels to Mac, something happens to the permissions and that's why it can't open.

I hope this helped.

This happens on my Mac exports too.

A few months ago I found a solution, it was something about permissions, and you had to do something in terminal to enable some permissions to the .app. It worked. But now I've completely lost where that info was located. So I'm stuck with a dysfunctional .app again.

It's a misnomer, I apologize. Moving it within screen has the same result. Press the button many times while at a higher position, then lower the whole text to a lower one, press it again more times. The new position is not along with the textbox like at the beginning, indicating that changing of X,Y position of textbox influences text.height or width return

----Correction. I simply didn't enter textbox.x and y

It was only a wave of massive retardation on my part. Fixed it now. ----

sorry bout that

UPDATE: Just checked it with latest Construct 2, the bug is still present.

[quote:h9n375et]Observed Result

Note that there is a delay of 0.1 for the new textHeigh&textWidth to be calculated

So the project DOES have a delay, and is within bounds, bug is still present.

The bug is present no matter if it's out of bounds, or near bounds. Please test the project out, the problem will appear obvious soon after.

For future bug posts, I will use latest version.

Thank you

I would love to get any feedback or maybe a solution to this since it's essential for a bigger project I'm working on. I have alternatives, of course, but if this is solved, it would help a lot.

Problem Description

Textbox textHeight and textWidth don't take work well when textbox is out of the boundaries of the project.

Attach a Capx

https://www.dropbox.com/s/fiegbhqxsrxq2 ... eport.capx

Description of Capx

A simple capx. with as little as possible elements to simulate what happens into my larger project when I try to determine textHeight and textWidth out of the screen (when the textbox itself is out of the screen, or further away)

Steps to Reproduce Bug

• Press "Push Me" a few times
• Drag the textbox to a lower region
• Press "Push Me" a few times again
• Drag the textbox to a higher region
• Press "Push Me" a few times again

Observed Result

The red line jumps erratically, like it doesn't know textHeight or textWidth. I can't use anything else, other than textHeight&textWidth since the text in my game changes dynamically and the red line needs to go under the text ,where it actually has text.

Note that there is a delay of 0.1 for the new textHeigh&textWidth to be calculated

Expected Result

The red line is always placed below the newly sized textbox, no matter if the textbox is near the top, out of bounds or middle.

Affected Browsers

• Chrome: (YES)
• CocoonJS: (YES)

Operating System and Service Pack

Windows 7 SP3

Construct 2 Version ID

Release 165

THANK YOU

I understand that, but I'd say that it is good common practice to not make user unable to cancel anything that lasts potentially 20 to 30 seconds.

It is just better user experience.

Thank anyway

The user looses control over what he is doing the moment it autosaves. Would be practical to give the user back control, and enable autosave delay every time you hit escape while it is autosaving.

This is particularly disruptive during good ideas, on big projects.

Also bumping to see if there is anything new on this subject. It seems like a really basic thing for text formatting.

A "pleasant" surprise :)

We might add a very "tasty" cookie unlock in the future :)