kristalsoldier
Well-Known Member
Another Mitch in the making!
I do have 1 gripe about metro UI
- Thread starter ChemCat
- Start date
As far as given one bit at a time, I'm not a developer and as I check this board through the day I may post something I think is applicable to the situation. I hear the frustration in your post, you are attempting develop for a specific use case and work flow. The Auto Complete was built into the predictive completion engine for the On Screen Keyboard. I've seen many Business Apps for Windows 8.1/RT that successfully use the OSK for input.
Even in your blog post, they actually did usability studies on how the majority of real people interact with the UI. In theory since you are planning on Side Loading the App, using the PowerShell Install Script you could import the Registry Key during the install. Your other option would be to head over to the MSDN Forums and see if there is a way to inject your Auto Complete Dictionary into the OSK Engine.
Even in your blog post, they actually did usability studies on how the majority of real people interact with the UI. In theory since you are planning on Side Loading the App, using the PowerShell Install Script you could import the Registry Key during the install. Your other option would be to head over to the MSDN Forums and see if there is a way to inject your Auto Complete Dictionary into the OSK Engine.
OP
ChemCat
New Member
Actually, the registry option is not an option. It will not only change the keyboard size for this app. It will change the keyboard size for everything everywhere.
I want to some day market this app. So, any kind of hacking is out of the question.
Yes, there is a built in autocomplete function. But there is no option at all to customize the predictions. The predictions are pretty much from a library and are limited to spell checking what the user wants to input. So, yes while this is useful in a business app, it is far from being useful in a real work app.
There actually are 2 built in autocomplete functions in metro. The first which I explained above is nothing more than a spell checker. The second is an honest to god drop-down menu of a custom list of words. But it is hard coded into the search pane contract in the charms bar. So, while it works great for a blog reader app, it is useless in a work app. Why? Because in any given situation or page, there needs to be at least several autocompleteboxes with dropdown suggestions. One box might be the item description. Depending on which item description you choose from the suggestion dropdown menu, another box would give you the item code for it. Then the box that now has the item code would have a dropdown menu of the corresponding mathematical values to use. Depending on what kind of project this is and what kind of yields we are looking for, the dropdown suggestions would give the list of values available for this specific situation. And so on and so forth. I wasn't kidding when I say traditionally, we engineers have to look through hundreds of thousands of values to look for that right one on-site there and then and then crank out pages of calculations. There are thousands of possible calculation routes to take, each one unique to the specific situation and design spec.
Back in the old wpf projects, autocompleteboxes were easy to write. I can write out one in no time with my eyes closed. But with metro, it took hundreds of lines of codes and hours and hours of headaches simply because the prereqs aren't even there. I had to do coding yogas to combine textboxes and listboxes, programmatically check for... screw it.
And don't forget about printing. The most basic function of any computing device. Why make coders jump through a kazillion hoops to print out a simple text string? I kid you not, if you want to print out a simple "hello world" text string, you have to write out 150+ lines of code. In wpf, it takes 4 lines. If you want your printout to look formatted and professional, it takes 200+ lines. Mine is around 250 lines of code. I've talked to coders by profession, and so far no one has found an easier way to write out a simple printing protocol for a metro app.
Yes, I'm frustrated. But I guess such is life. When I finally market this app, it will be one of a kind I guess.
I want to some day market this app. So, any kind of hacking is out of the question.
Yes, there is a built in autocomplete function. But there is no option at all to customize the predictions. The predictions are pretty much from a library and are limited to spell checking what the user wants to input. So, yes while this is useful in a business app, it is far from being useful in a real work app.
There actually are 2 built in autocomplete functions in metro. The first which I explained above is nothing more than a spell checker. The second is an honest to god drop-down menu of a custom list of words. But it is hard coded into the search pane contract in the charms bar. So, while it works great for a blog reader app, it is useless in a work app. Why? Because in any given situation or page, there needs to be at least several autocompleteboxes with dropdown suggestions. One box might be the item description. Depending on which item description you choose from the suggestion dropdown menu, another box would give you the item code for it. Then the box that now has the item code would have a dropdown menu of the corresponding mathematical values to use. Depending on what kind of project this is and what kind of yields we are looking for, the dropdown suggestions would give the list of values available for this specific situation. And so on and so forth. I wasn't kidding when I say traditionally, we engineers have to look through hundreds of thousands of values to look for that right one on-site there and then and then crank out pages of calculations. There are thousands of possible calculation routes to take, each one unique to the specific situation and design spec.
Back in the old wpf projects, autocompleteboxes were easy to write. I can write out one in no time with my eyes closed. But with metro, it took hundreds of lines of codes and hours and hours of headaches simply because the prereqs aren't even there. I had to do coding yogas to combine textboxes and listboxes, programmatically check for... screw it.
And don't forget about printing. The most basic function of any computing device. Why make coders jump through a kazillion hoops to print out a simple text string? I kid you not, if you want to print out a simple "hello world" text string, you have to write out 150+ lines of code. In wpf, it takes 4 lines. If you want your printout to look formatted and professional, it takes 200+ lines. Mine is around 250 lines of code. I've talked to coders by profession, and so far no one has found an easier way to write out a simple printing protocol for a metro app.
Yes, I'm frustrated. But I guess such is life. When I finally market this app, it will be one of a kind I guess.
Last edited:
If we were to assume that an On Screen Keyboard registry setting exists, and that an App could modify that on activation, could it not reset the value via the OnVisibilityChanged event. A smaller OSK may never show anywhere else.
Of course, a fully customized keyboard offers all sorts of advantages for a particular task. That may even be the factor that makes or breaks a LOB application above, say, and Excel spreadsheet alternative.
OP
ChemCat
New Member
Well, I could have told you this. And it's kinda obvious. In fact, I would prefer the metro app not having access to the registry.
And again, for a legit app like what I'm working on, hacking is not an option. Part of the reason I'm frustrated with MS. They claim one thing, but they're not really showing it.
If you do a search for how to build windows store apps for beginners, most results will be of how to build a kick-ass blog reader. Get a clue, MS. Stick with productivity. If I want to scoop out my brain and become an airhead blogger for a career, I'd go with iOS or android.
Could it be ChemCat, that MS deficiencies with their soft keyboard and your suggested poorly designed auto complete, could provide a coder like yourself an opportunity to make some money fixing these deficiencies?
I have on occasion ran into problems where I can't see what I'm tying into a form or something. I wind up working around it one way or another, such as grabbing my keyboard out of my bag and attaching it temporarily.
I have on occasion ran into problems where I can't see what I'm tying into a form or something. I wind up working around it one way or another, such as grabbing my keyboard out of my bag and attaching it temporarily.
OP
ChemCat
New Member
Well, not really. Any change to the keyboard has to be done within the app. The virtual keyboard in metro is completely off-limits. Meaning I can't do anything to it at all.
So, in my app what I have done is write out a subroutine to trick the system to not see the textboxes. But I also want to be able to input into the textboxes whenever I have the touch cover attached. So, there's another subroutine that scans for any physical keyboard attached to disable the other subroutine. But then I had to write another method to allow my custom keyboard to input into the textboxes through the smokescreen. This was also tricky to write, considering at any instance there are at least 5 layers of usercontrols (usercontrol within a usercontrol within a usercontrol...). And the mother usercontrols are generated by the c# code to allow the user more control over what's being calculated and what to print out. It's complicated.
Anyway, the point is since the keyboard is off-limits, I can't really help other people with their apps. All I can do is put up a smokescreen to trick the virtual keyboard from detecting input fields.
Added by edit.
And get this. MS has not provided any library to generate a pdf file. Get it? One of the most basic functions of a business app is not here at all. What they did provide is a way to generate a bitmap. Through many nights of tears and sweats, I finally managed to write out a working class to generate a pdf from the bitmap.
MS really is not making it easy for those of us who are not coders by profession.
So, in my app what I have done is write out a subroutine to trick the system to not see the textboxes. But I also want to be able to input into the textboxes whenever I have the touch cover attached. So, there's another subroutine that scans for any physical keyboard attached to disable the other subroutine. But then I had to write another method to allow my custom keyboard to input into the textboxes through the smokescreen. This was also tricky to write, considering at any instance there are at least 5 layers of usercontrols (usercontrol within a usercontrol within a usercontrol...). And the mother usercontrols are generated by the c# code to allow the user more control over what's being calculated and what to print out. It's complicated.
Anyway, the point is since the keyboard is off-limits, I can't really help other people with their apps. All I can do is put up a smokescreen to trick the virtual keyboard from detecting input fields.
Added by edit.
And get this. MS has not provided any library to generate a pdf file. Get it? One of the most basic functions of a business app is not here at all. What they did provide is a way to generate a bitmap. Through many nights of tears and sweats, I finally managed to write out a working class to generate a pdf from the bitmap.
MS really is not making it easy for those of us who are not coders by profession.
Last edited:
A programmatically inaccessible “Registry” is an interesting concept to begin with. Isn’t the Registry the method of storing application specific settings in a singular database, eliminating the need for a glut of .ini files.
I should not have been surprised that system wide specifications were set off limits, given Windows RT’s mandate, it just caught me off-guard that a vendor does such a complete 180. Conceivably, the RT Registry as an entity is something like our Tonsils or our Appendix – a feature of dubious purpose, in the process of morphing into something unrecognizable.
Last edited:
Nuspieds
Active Member
Although it has not been a problem for me, I definitely understand and see his point.
The reason it has not been a problem for me is that I use the onscreen keyboard for typing, so large keys are important.
However, the reason I see his point is that even when I first purchased an iPhone, I was disturbed that I could not customize the onscreen keyboard. Clearly, depending on the use case, the onscreen keyboard needs customization options; there is no way that one size fits all. The default should be as-is (type mode) but being able to resize/customize it should be there out-of-the-box.
Nuspieds
Active Member
I wouldn't say that they weren't serious about the Modern UI at all; rather, it is just that they were late to the game and rushed it out the door.
For me, there are significant features lacking in the Modern UI (especially when compared to the Desktop UI), but it will just take time before it becomes mature and has a feature set that at least stands up to the Desktop UI. As an example, I am still waiting to be able to organize my Live Tiles into a nested folder structure and to be able to customize the icon/color/text for my Live Tiles.
Similar threads
