I'm writing a WinRT game for Windows 8, in C#, using the excellent MonoGame. I've reached the part where the user has achieved a high score and needs to enter their name. This is causing me more pain than I'd anticipated so I thought I'd ask for help.
First of all, is there a simple "enter some text" function that I can call, similar to Guide.BeginShowKeyboardInput in Windows Phone 7, or the ancient InputBox command in VB? I'm using Windows.UI.Popups.MessageDialog for displaying simple dialog messages, but can't find any similar thing for requesting text from the user.
Failing that, is there a way I can easily use a little piece of XAML to present a textbox for the user to use?
If neither of these are possible, I guess I'll have to wire this all up myself... I then would plan to intercept keystrokes and display the required text on screen myself. As I don't have a physical tablet (just the simulator) I'm struggling to start with this. How can I:
Detect whether the device has a physical keyboard, so I know whether or not to display the on screen keyboard?
If there is no physical keyboard, how can I show and hide the on screen keyboard?
Some of these sound like they should be easy to answer, but I've yet to track down answers to any of them.
Many thanks!
Adam.
Hey there is such a way to do this in monogame. There is a new template that allows you to create a XAML + Game game which allows you to use the game class you a used to with the xaml bits as well. These links should get you started. The monogame team rocks.
There are the three game types listed there. You want XAML + Game there is a template for it now if you get the proper version of monogame.
https://github.com/mono/MonoGame/wiki/Windows-8-Project-Types
let me know if you need more help
This is not a cross platform solution but you could use a FlyOut and place the controls for data entry on the window. FlyOut guidelines are here and UI Controls for text input guidelines are here. I have also used MessageDialog in a MonoGame for asking the user simple questions (up to 3 options) or to get a Yes|No response. You can get details of that class here.
Related
I have been trying to build a TV application, using an SD.
I have got features like image gallery, video player running,
However, I also wanted to add a virtual on-screen keyboard that works with up-down left-right arrow keys. Can somebody help me with how to get started?
When I wanted to do this with my Vestel (Polaroid Branded) smart TV, which uses "Opera for TV devices" as it's HbbTV browser, I found that I didn't need to.
I simply just used HTML text fields and input types where needed, and as soon as I clicked into them, the browser/OS kernel popped up an onscreen keyboard that was built in for me.
However, I did do some research to see if I needed it, and on some devices you do, whilst I never actually implemented it (My app was just for my own use) the "BBC Television Application Layer" (TAL for short) : https://github.com/bbc/tal had pretty good keyboard support.
Another one that might be worth looking at is "Mautilus SDK" : https://github.com/mautilus/sdk
Be aware though, both are horribly convoluted and use quite complex code where it's really not needed.
I am new to the android development platform and working on a project to write some test comparing some of the different gesture keyboard implantations (android 4.2 built in, swipe and swift key).
I am using eclipe for my IDE and relying primarily on the emulator for testing. I am using the 4.2 gesture keyboard from here (http://forum.xda-developers.com/showthread.php?t=1964663).
What I would like to be able to do (starting with android 4.2 built keyboard).
Pass a string in, for example “hello” and then have that string entered using the gesture keyboard.
Get the words shown in the Candidates View box.
Compare the words to an expected word and return pass/fail depending on if the words returned from Candidates View were what I expected.
Store passed in word and returned suggestions in a log file for analysis.
Ideally I would like able to use API’s only for this and not reply on UI but I am not sure if this is possible.
Some possible solution I am looking at.
Use TouchUtils class (http://developer.android.com/reference/android/test/TouchUtils.html) to draw shapes between keys. However, I am not sure how I can specific x and y coordinates on device to map to specific keys. Also I don’t see any methods in this class that would let me draw a custom based shape.
Also I see the sendKeys(String keysSequence) however this looks like it just presses key and would not exercise to gesture keyboard stuff.
So I am curious how all you advance android developers would approach/solve this problem and if there is already any resources/API’s out there that can help.
Thanks
Pete
You can try MonkeyRunner tool
http://developer.android.com/tools/help/monkeyrunner_concepts.html
Or you can try "Programmatically Injecting Events on Android" in the below two blog posts (part 1 and part 2)
http://www.pocketmagic.net/2012/04/injecting-events-programatically-on-android/#.UckpTZwlubq
http://www.pocketmagic.net/2013/01/programmatically-injecting-events-on-android-part-2/#.UckpSZwlubp
To scratch a personal itch, I'm writing something like a cross between a character map and an on-screen keyboard. When the user selects a character, I'd like to insert it into another application, specifically, the application that would next receive focus if my application were closed. Is there any way to do this? Right now, I work around it by just putting the character into the clipboard and terminating, leaving the user to hit paste in the other application, but usage would be far more streamlined if I could just insert the text programmatically.
I'm doing this in GTK and expect to run it only on Linux. But cross-platform solutions are also appreciated, and if GTK can't do it but some other toolkit can, I'll gladly switch.
This sounds like you should use libwnck, which is a GTK-related library that lets you manipulate windows on the desktop. The documentation is a little sparse, but the function wnck_screen_get_previously_active_window() seems promising.
From a WnckWindow you can get an X window ID, and perhaps from there you can use the X libraries to send a paste message (or even send it a "Ctrl-V" keypress event), perhaps with XSendEvent().
Very good question, by the way. I wish I could answer it more knowledgeably.
How (i.e. using which API) is the virtual keyboard opened on Symbian S60 5th edition? The documentation seems to lack information about this.
You are right, this should obviously be a published API and it should be highlighted in the documentation. No such luck.
If you are using one of the platform native controls, the virtual keyboard will automatically popup when the user accesses a text-editing control.
If you are making a custom control, you need to deal with its selection by adding your own version of the virtual keyboard: make a new text-editing, window-owning virtual keyboard look-alike custom control with the right buttons. Reuse it accross all your applications. One day, Nokia will realize they have made an obvious mistake and make the API publicly available.
If you are using direct screen access, well, you wouldn't exactly expect the very s60-looking virtual keyboard to popup out of nowwhere. Again, draw a nice image on the screen to let the user know where the virtual keys are and react to pointer events. This is going to be less reusable unless you build a good amount of customization (background, button edges...) into it.
EDIT: Nokia may be relying on Qt to fix this issue. I would expect the control to be part of the current 4.7 version of Qt.
Tinkering with focus on a QLineEdit inside custom coded kinetic scroll area, I've had a simmilar problem (how to open virtual keyboard manually). Then, I found it, this obviously works in Qt 4.6.3 on a C7 Symbian^3 phone:
// lineEdit is an instance of QLineEdit
QApplication::postEvent(lineEdit, new QEvent(QEvent::RequestSoftwareInputPanel));
Before that, I also had to post a QEvent::FocusIn event to that same lineedit, otherwise the QLineEdit did not update the content from virtual keyboard.
Hope this is helpful. I lost hours.
Thank you tihi, very useful tip! There's also the "close virtual keyboard" event that can be triggered:
QApplication::postEvent(lineEdit, new QEvent(QEvent::CloseSoftwareInputPanel));
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.