I want to know the event in blocks section using which the entered text value can be obtained without a form submission through button.
Let's say user inputs text in mobile phone through keyboard and presses enter. In this case I want some event to trigger and get the value that user entered.
There are 2 events available like lostfocus and gotfocus.
Will these work? Or is there any other good approach for getting text value on pressing enter?
Unfortunately there is no such event like OnEnterPressed available in MIT App Inventor and the events LostFocus and GotFocus will not work in this case.
What you currently can do is
use a button and use the Button.Click event, or
create your own custom keyboard, see also this example
Currently there is a limitation for App Inventor extensions, which only can be used for non-visible components. Later as soon as also visible components are doable, then you could write your own textbox extension and add an event yourself.
Edit concerning the new question in the comments about different screens:
Use different screens wisely
Before starting to create another screen, first you should think about is it really necessary? See also Building apps with many screens and SteveJG's post about advantages/disadvantages, because in only one screen you also can use vertical arrangements to simulate different screens, just set the arrangements to visible = true/false as needed...
You can insert a Clock component that monitors the TextBox1.Text. When it triggers, it checks if the TextBox1.Text has changed and saves it to a variable. When it triggers again, it compares the variable with TextBox1.Text. After the user finishes typing, the variable and TextBox1.Text will be equal and then you can trigger the event like you eanted when the user pressed Enter.
Hope this helps!
Related
I am trying to identify if a TCommonDialog (Open, Save etc) is active in my application but they do not appear to trigger OnModalBegin or change the Application.ModalLevel despite clearly having modal status.
I am intercepting keyboard events in my application and I want to pass through these keybaord events under some conditions. One of the conditions to do the pass through is a dialog box being open but I cant find a way to detect this.
Is there a way to know when a decedent of TCommonDialog is active?
I have a ranorex project, which automated an use case with clicking 5 buttons in an application.
To set up this project I used the record function. I defined some sleep times between the clicks.
The run with the clicks is in a loop, where the loop count is dynamically defined. One button of the five and always the same button, Ranorex "ignores" sometimes. According to the log file, the button is visible and enabled and ranorex also runs the code with the Click(), but the application doesn’t receive the click. Before in code the click is called, I check with an “If” whether the button is visible and enabled - and if the click() is called (or doesn't), I log it to ranorexlog. Sometimes the application is running through and all the clicks work and sometimes this button click is missing one or more times. It doesn’t depend on the sleep time between the clicks, because I tried long and small pause times. It doesn’t depend on the focus of the application, too, because I switched the focus several times.
Does anybody know this problem, workarounds or what I’m doing wrong?
the obvious workaround is to use Mouse.Click("{Button}") with a 0 duration rather than invoking the click event, or if you are invoking the mouse click invoke the buttons click action. (sorry since they are both named Click() i don't know which one you are using).
As to what is happening, from your description it sounds like your script is finding more than one element with the same xpath. This would cause issues with the click event because it may try to click on the element, but it's the first xpath that matches not the second. Are there any optional elements in this sequence of button clicks that appear? for instance a busy spinner with inner text of "OK" that is hidden from view when you are clicking a button on a form with inner text of "OK" would cause two elements to be found if the xpath was looking for an inner text of ok. This element that is causing may not have been caught in the recorder because it might not have been present at the time.
Another possibility if you are using Mouse.Click() (particularly if this is a website)is that it is possible your button is not actually on the screen, I know that should be taken care of by the visible check but it is visible on the dom even though it is not visible on the screen that causes issues.
I highly recommend do not use the recorder to create test suites that need to be re-runnable. It would actually be better to use the spy tool to create a repository or several repositories for the product you are testing, this way you can be sure the xpaths are all unique, which using the recorder there is no gaurantee. You can actually record with the created repository, and ranorex will attempt to find item in the repository before creating a new item, so the recorder will use this repository when creating recordings.
I have an interesting observation and question, but first a comment. I have been using Delphi for 14 years and have taken a job developing an iOS mobile application using XE5. This is my first time using FMX and frankly I feel like I am stepping back in time many moons ago. In other words, if this is the future, then it feels like I have crippled. No problem though. Roll with the punches. Developing in this brave new world is not just a job. It is an adventure.
Now my question. Start a FMX mobile project using the "Header/Footer with Navigation" as your base. Then add an edit control (Edit1) to the first tab item. Then set the tab control align to none and move it to the right until you can clearly see the form itself. Then add an edit control (Edit2) to the form.
Now set the form's active control to Edit1 and run the app - no focus on Edit1. Now set the form's active control to Edit2 and run the app - focus is placed on Edit2. Interesting. Tab is a foreign word to tablets, right? Why have active control or even setfocus available? Is this an oversight by Embarcadero? Any thoughts?
Long story short I think they both have potential uses.
I use the SetFocus call to manually show the keyboard. Lets say the user navigates to a page where they're 100% sure to be putting in their username (or any text), I'll use ctrl.SetFocus to show the keyboard just to save them having to click (or is it press now?) on the edit.
I don't see ActiveControl being as useful, but it could definitely still be used. You could possibly use it to set up some sort of tabbing like structure for when the user presses Next on the keyboard (when the edit's ReturnKeyType is rkNext).
I'm wondering if there's an easy way to tell which input device triggered a particular GUI event.
For example: A TButton.OnClick event gets fired. Did the user trigger it with a keyboard press (shortcut, Enter key for default button, space key for a focused button, etc.) or was it triggered with a mouse click? Is there any easy way to tell?
The reason I'd like to know is so that I can implement keyboard usage hints into some of our applications when the user uses the mouse to initiate actions that could also be done with the keyboard. Our systems on the shop floor are in pretty dusty/dirty environments, and mice tend to not hold up so well in them. Also, in many cases, there's simply not that much room for a mouse to be used. (No, keyboards without numeric keypads is not a solution. They're relied on too heavily.)
However, since our apps run in Windows, users tend to simply use the programs like they would at home -- with a mouse. There's nothing particularly wrong with that, but we've worked hard to optimize the input workflow to be keyboard friendly as well. It'd be nice if there was a low-impact way to indicate to our users that there's a way for them to do the things they're doing without having to grab the mouse.
There's no way to tell from within OnClick. However, you can also attach events to a control that will fire when the mouse rolls over it, which would probably be more appropriate for what you're trying to do anyway. Take a look at the OnMouseEnter and OnMouseLeave events. Also, if you really want something specific to happen when the mouse is clicked, you can attach it to OnMouseUp.
Question:
Can anyone point to an article or code samples anywhere on how to
provide BOTH editing AND range selection in a TStringGrid?
Yes, I KNOW there are third-party grids that do this, but it's
frustrating that the built-in grid lacks this basic capability.
Background:
It's pretty normal to expect to be able to both edit a cell in a grid,
and also to select a range of cells such as for a Copy operation.
As delivered, TStringGrid doesn't do that. It's either/or. In fact, the
docs tell us about the grid Options, "When goEditing is included in
Options, goRangeSelect has no effect".
However, it looks like it may be possible to do editing and rangeselects
in a TStringGrid anyway!!! Through careful use of the mousedown,
mouseup, selectcell and exit events, you can get dang close by switching
editing elements on and off at the right times. But I still don't have
it perfect, and that only covers mouse use, not keyboard changes.
I have not used the TStringGrid for this, so I can't provide a specific answer. But am I right in assuming you can manually (in code) start a cell being edited? That link implies it is possible even if the grid doesn't have goEditing included in its Options. (See below to work around this if this is not true.)
If so, I'd suggest the following approach:
Combined selection and edit behaviour
I find this is a good, Windows-standard-behaviour sort of approach:
Leave the grid in selection mode, so mouse and keyboard interaction selects cells
Trigger a cell being edited yourself, based on certain criteria (I think you are on the way to doing this from what you said in your last paragraph.) There are common ways to trigger editing, and the following criteria are what my programs follow when they do something similar with other controls:
Selection is normal. Ie, click to select, click and drag to multi-select, use the keyboard arrows and Shift or Control to select, etc.
A cell enters edit mode when either:
A cell is selected and the user presses Enter or F2 (F2 is the standard "Rename" or "Edit" shortcut, which works in a number of programs)
The user "slow-double-clicks" on a cell - ie, slow-double-clicks to select and edit, or clicks again, after a pause, on an already-selected cell. This mimics Explorer's behaviour, where if a file is selected and you later click on it, it enters the inline edit/rename mode. To implement this, record when a cell was last clicked (and selected.) If it is clicked again, and if the time is greater than GetDoubleClickTime then they have clicked twice, slowly, and enter edit mode. This allows you to distinguish between the first click to select, a double-click (to perform some kind of action), and a slow second click, to enter edit mode.
I also tend to check the mouse position, so that if an object is slow-double-clicked and it wasn't first selected (ie, this both selects the object and then enters edit mode) I verify the mouse hasn't moved very much. I use GetSystemMetrics to find the double-click distance, and check that the slow double click was within this box. (Because it's not a true doubleclick, I actually check the distance times 2. My action code is:
const int iMAX_MOVE_AMOUNT = ::GetSystemMetrics(SM_CYDOUBLECLK) * 2; (sorry, C++ not Delphi, but should be convertable easily enough!)
but I'm actually not certain if this is completely and utterly 100% to Windows guidelines. In practice users find it works as they expect, though.)
That should let you change between selecting and editing at the appropriate times with both the keyboard and the mouse.
Miscellaneous thoughts
You may find some of this is cleaner and easier to implement by subclassing TStringGrid and creating a new component. That will allow you to implement this in normal code and override the inbuilt behaviour (rather than event handlers) while keeping it invisible to the form code. It will also give you lower-level access to the mouse events or Windows messages than are exposed simply through events such as OnMouseDown. Finally, if there are problems with showing the editor when goEditing is included in Options, this will allow you to change that behaviour. You could also add your own events if you want your code to respond to certain things happening, such as creating an OnBeginEdit event, say.
Creating your own components is normally regarded as an advanced Delphi topic, but it's actually remarkably easy once you know how! This site has a few good topics that will introduce you to the subject in general, and if you go this route and encounter problems, Stack Overflow is of course a good place to ask questions :) The Embarcadero Delphi » VCL » Writing Components newsgroup / forum is also an excellent resource, in fact possibly even better than SO for this specific topic.
Hope that helps!
Yes it's old post, but the problem still exist on Delphi XE3.
To manage this feature I used next "trick" in SelectCell procedure :
if (ARow = StringGridParam.Row) then
begin
StringGridParam.Options:= StringGridParam.Options + [goEditing] - [goRowSelect];
end else begin
StringGridParam.Options:= StringGridParam.Options + [goRowSelect] - [goEditing];
end;