Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / EditBox problems

Author
Message
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 20th Nov 2017 22:36 Edited at: 20th Nov 2017 23:12
My app is getting to the point where it needs a way for users to chat with each other privately but because of all of the problems I've found with edit boxes I can't see it happening with AppGameKit which is disappointing as I love working with AGK. The other disappointing thing about it is that I prefer creating apps then games and there's not many decent/useful apps you can make without a textbox!

Anyway here's a list of all of the problems I've collated in the hope that one or two of them will one day be looked at and sorted. I was only able to test these on a Mac and an Android device.

* ANDROID: Type in random keys without pressing space and then hold down the delete key and it will delete all characters until you let go. Great! Now type in random keys, press space, some more random keys and then hold down delete it will stop at the place where you added the space. It will delete the space but won’t continue. And now you can’t hold the delete key down anymore and have to press delete repeatedly for all characters in the first part of the text.

* ANDROID: There’s no way of finding out the keyboard height so you can’t correctly position the edit box above the keyboard and be confident it will be the same on all devices. You have to position it because the keyboard covers it if you’ve got the edit box at the bottom of the screen. I know there’s SetEditBoxUseAlternateInput but…

* ANDROID: SetEditBoxUseAlternateInput(index, 1) creates a very tiny textbox. Why doesn’t it have the same size and style we’ve set the edit box? Why not just position the edit box above the keyboard instead of creating a teeny weeny textbox that doesn’t fit in with any style?

* MAC & ANDROID: Pressing enter doesn’t increase GetEditBoxLines() count until you start typing even though the cursor is on a new line. Was using this to autosize the edit box as they type like you’d see when typing in WhatsApp. If you press enter GetEditBoxLines should increase. Here's an example of an edit box that resizes with the number of lines. I couldn't do this on it's own: SetEditBoxSize(txtBox, 85, GetEditBoxLines(txtBox) * 5) because if the edit box is empty then GetEditBoxLines returns 0 so the size of the box ends up with a height of 0.



* MAC: You can’t press the cursor keys in an edit box to move the cursor because it inserts square ascii characters instead of moving the cursor. I’ve raised this before and it will hopefully be fixed in the next version of AGK.

* MAC & ANDROID: The cursor isn’t vertically centred. To make it look neat you have to remove borders and add a white sprite behind the edit box with an offset so that the cursor looks vertically centred. Yeah ok I'm probably being a bit picky here...



*ANDROID: Emojis show as a square ascii character.

*ANDROID: There’s no default text option for when the textbox is empty. It’s easy enough to program though:



* MAC & ANDROID: No alignment.

* MAC & ANDROID: No select, copy and paste (but we all know this).

* ANDROID: GetPointerPressed() doesn't register when the keyboard is showing so you can't have a button next to the text box that sends a message. Well you can but it takes two clicks to register the button was pressed and therefore send the message. Just remembered this one. This is another one I reported before and should hopefully be fixed in the next version of AGK.

Anything else I've missed?
Dybing
12
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 21st Nov 2017 00:21 Edited at: 21st Nov 2017 00:46
AGK isn't really suited for UI heavy apps. AppGameKit is more for multimedia heavy apps, and as the name suggest, that includes games.

For UI heavy apps (on phones and tablets), your best bet is going for a hybrid solution using either the Xamarin stack or a Web stack. Xamarin is probably easier to learn, as you can do everything inside VS2017 using just C# and XAML - and with minimum effort you can even push out versions for Windows10 and XBox if Android and iOS isn't enough. Best of all, you can do both frontend and backend in the same language, and C# on dotnet core is quite nice as far as languages go, so even less to sit down and digest before getting started.

Getting native performance out of a web-stack is a bit more cumbersome. The best bet would be NativeScript + TypeScript + Angular4 + HTML + CSS, all of it resting on a nice bed of nodeJS. And that is just the frontend, and for Android and iOS only. For backend, you need master yet another little stack of tech containing a language, a framework and a webserver. Or do as I do, dump the web-framework-server dependency hell and use Go for doing the backend APIs. Server functionality is in the standard libraries

Either way, going hybrid means you get a ton of tools for making functional and native UI elements entirely for free. It may be daunting at first, and the process certainly is different than in AppGameKit, but the good news is that there are plenty of good guides on how to get started.
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 21st Nov 2017 01:13 Edited at: 21st Nov 2017 01:16
Thanks Dybing but I'm not ready to look at re-writing it in another language. I've created all of the UI elements from scratch and I've been ok with AppGameKit not having the UI elements that you would find in the languages and toolsets/development suites you've listed above. I would probably class my app as UI heavy but I've been able to achieve most of the UI elements I've needed, it's just these darn textboxes that let it down, and would let down most non-gaming apps in AGK. I used GameSalad quite a lot before settling down with AppGameKit and GameSalad had the same problem, poor textboxes.

I do understand that creating a proper non-gaming app is best suited for other languages but I've looked at quite a few in the past and the learning curve was just too much and then there was the problem with finding one that had a good cross platform range when exporting.

It may be something that I look at in the future when I realise that I need to target more platforms than Android and iOS which I think is pretty much all I can do with this app in AppGameKit as it relies on in-app purchases. But for now I'm going to stick with AppGameKit as it's an app that was missing from the market and AppGameKit was and still is (for me) the best language to build it in. If I tried another it probably never would have been built at all. I would probably look at Tier 2 first though to see what extra stuff can be done with that to see if it's worth learning and porting later on.

I've been limiting the need for textboxes the best I can. The app only contains two so far. But it definitely needs a way for the users to send feedback to each other. A simple private messaging system would have been perfect.
RickV
TGC Development Director
23
Years of Service
User Offline
Joined: 27th Apr 2000
Location: United Kingdom
Posted: 21st Nov 2017 08:22
@Kevin Cross - I'll ask Paul to read and comment on all your points. Edit boxes still seem incomplete and this is clear from your report. Hopefully we can patch up some of the issues for the next build and later on we add some much needed enhancements.
Development Director
TGC Team
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 21st Nov 2017 09:00
You could do what I (and a lot of other people have done) and code your own text entry system.
Not ideal, but you get 100% the system you're after.
Click here for VR Legend of Zelda stuff
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 21st Nov 2017 12:06 Edited at: 21st Nov 2017 12:08
@RickV thank you. That sounds promising!

@Mobiius, I have considered that in the past (not recently) I event created a keyboard laid out on the screen but it can pretty complex quite quickly if you're trying to replicate the device keyboard. For entering a name on a game for a high score board I can see how creating your own would be ok and at least that way you can style it to your game.

On a slightly different note is there any documentation or comparison charts to show the difference between Tier 1 and Tier 2 please? I know that Tier 2 is C++ which uses AppGameKit built functions like Tier 1, and I've seen it mention on the forums that it's quicker but I can't see what can be done in Tier 2 that can't be done in Tier 1. I guess initially I'm interested in knowing if we can add other SDK code in to our AppGameKit Tier 2 programs, so for example if I wanted to release it on Amazon could I use the Amazon in-app SDK code to allow for in-app purchases? And likewise add in different ad networks with the SDK's that they all provide? Is there anywhere that lists what can and can't be done in Tier 2? I did do some Google searching this morning.
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 21st Nov 2017 13:11
Quote: "what can be done in Tier 2 that can't be done in Tier 1."

Integrating third party plugins. Object oriented design. Better compiler/debugger.

That's pretty much it. The core of AppGameKit is identical.
Click here for VR Legend of Zelda stuff
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 21st Nov 2017 17:35 Edited at: 21st Nov 2017 20:25
i still have the plan to test vs code with c++ (because oop) & agk and having a dll to expand basic projects.
in the past i done a gui system in one week
edit:
so today i tryed to setup this vs code editor^^ arrggg
AGK (Steam) V2017.09.25 : Windows 10 Pro 64 Bit : AMD (17.11.2) Radeon R7 265 : Mac mini OS High Sierra (10.13)
LillyByte
6
Years of Service
User Offline
Joined: 30th Oct 2017
Location:
Posted: 25th Nov 2017 08:10
I'll back this one; Edit Boxes in AppGameKit are thoroughly broken in HTML5 too.

User input is a nightmare with them; it does something funky to keyboard layouts and half the keys don't work except for A-Z, 1-0, and some punctuation. But keys like colons and semi colons simply don't exist when exported to HTML5.

I just want them to work.

~~ LillyByte ~~
http://www.dymoria.com
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 28th Nov 2017 21:55
Quote: "type in random keys, press space, some more random keys and then hold down delete it will stop at the place where you added the space. It will delete the space but won’t continue."

I can't replicate this on my Android device, but the text entry on Android is using a hidden OS edit box to accept input, which is then copied into the AppGameKit edit box, so it is probably a feature of the OS edit boxes on that device, to prevent you deleting too many characters. Manufacturers are free to modify Android behaviour for their devices, my test device was a Nexus 5 running stock Android.

Quote: "There’s no way of finding out the keyboard height so you can’t correctly position the edit box above the keyboard"

I'll have to investigate if there is a reliable way to do this, I think I had a look before but it varied widely. You can probably assume it covers half the screen.

Quote: "SetEditBoxUseAlternateInput(index, 1) creates a very tiny textbox. Why doesn’t it have the same size and style we’ve set the edit box?"

This is a hack that uses the old input method when the editbox may be hidden for backwards compatibility, which is the small input box you are seeing. The best method would be to move your edit box to the top half of the screen and disable the alternate input.

Quote: "Pressing enter doesn’t increase GetEditBoxLines() count until you start typing even though the cursor is on a new line"

Fixed for the next version

Quote: "You can’t press the cursor keys in an edit box to move the cursor because it inserts square ascii characters instead of moving the cursor"

Fixed for the next version

Quote: "The cursor isn’t vertically centred"

Fixed for the next version

Quote: "Emojis show as a square ascii character"

This will depend on the font being used, if it doesn't have the given character it will draw a square instead.

Quote: "No alignment"

Need more details

Quote: "No select, copy and paste (but we all know this)."

Something for the future

Quote: "GetPointerPressed() doesn't register when the keyboard is showing so you can't have a button next to the text box that sends a message"

Fixed for the next version
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 28th Nov 2017 22:18 Edited at: 28th Nov 2017 22:19
Thanks for replying Paul

Quote: "I can't replicate this on my Android device, but the text entry on Android is using a hidden OS edit box to accept input, which is then copied into the AppGameKit edit box, so it is probably a feature of the OS edit boxes on that device, to prevent you deleting too many characters. Manufacturers are free to modify Android behaviour for their devices, my test device was a Nexus 5 running stock Android."

I'm using a Samsung A5 2017 model. I don't see how it can be a manufacturer thing as I don't experience the problem in other apps.

Quote: "This is a hack that uses the old input method when the editbox may be hidden for backwards compatibility, which is the small input box you are seeing. The best method would be to move your edit box to the top half of the screen and disable the alternate input."

This is what I currently do.

Quote: "This will depend on the font being used, if it doesn't have the given character it will draw a square instead."

I'm using UseNewDefaultFonts(1). None of the emojis worked. Ok I didn't try every single one but I tried quite a few of the generic smileys that you get on an Android keyboard.

Quote: "Need more details (regarding alignment)"

You can't align text to the center of the edit box or right align etc. For one part of my app the user types in a 20 character ID to restore data to the device. And that would have looked nicer if the code they typed was centered. It's not a biggie. I did consider having the editbox resize as they type and constantly centering it. If it had a white sprite behind it the user wouldn't see it resize but I think I got lazy.

Quote: "Something for the future (regarding copying and pasting)"

I'm glad it's something that you're going to at least consider. Hopefully it will make it in a near future update. It'll be nice to be able to share codes and have the user copy and paste from one app to the AppGameKit app without having to solely rely on QR codes containing these unique codes because they're too long to type. You can ShareText and send it through WhatsApp but the recipient has no way of getting that string into their copy of AppGameKit without typing it manually which leads to typos etc. and switching back and forth between the two apps to see what characters they need to type next. This is obviously my need for it but I'm sure there's many AppGameKit devs wanting to be able to copy and paste.

And thanks for all of the fixes you've done so far. The GetPointerPressed one will definitely be a nice fix.

Login to post a reply

Server time is: 2024-04-25 06:36:45
Your offset time is: 2024-04-25 06:36:45