Is this possible at all? When I create a form using MonoTouch.Dialog, it comes automatically with the "next" button, but that jumps to the last input in the form. Is this a bug, or is it because I have to set a tabindex of sorts to make it work?
It should jump to the next input line, is that not the behavior that you are experiencing?
A test case would shed some light.
Ah, I found the answer on github. My bad, I should've looked more thoroughly there first. On the GetCell of the EntryElement, inside the entry.ShouldReturn foreach-loop, you need to break after setting focus to the next input.
https://github.com/SuperYeti/MonoTouch.Dialog/blob/master/MonoTouch.Dialog/Elements.cs#L1096
Related
I wanted to use the TextInputLayout/TextInputEditText in my app and was looking for ways to style this. Now there are lost of paged when you start googling on it but it also seems some thinks have changed in the current android version.
Do not misunderstand the pages where very usefull but did not supply a complete answer.
For that reason i am posting my end result here so others may benefit.
Before i explain in the answer below i want to thank Dmytro on his blog here as it was the most usefull.
The answer.
I made my example very colorfull to make it easier to understand.
To get to this result i used the following in my layout. sorry that it is not code but a picture but i did this so you can see the actual color and not just my name for it
Not a color thing, but as you can see i set the app:errorEnabled to true. this is done so the space needed for the error is already reserved which means your layout wil not rescale when there is an error.
the last thing you need it the border_color.xml:
Play around with the option to see what they do.
The only thing i did not manage to do in the layout is to change the color of the selectionHandles. I did find a code solution for it but...i'll keep looking.
I have seen questions asking if they can remove the maximize button, but I want to ask if it is possible to remove/disable the close button?
The answer is the same as the answer in the question you linked to. Only a slight change is necessary.
self.setWindowFlag(QtCore.Qt.WindowCloseButtonHint, False)
The CustomizeWindowHint flag needs to be set first before the WindowCloseButtonHint flag can be changed.
See https://stackoverflow.com/a/27496734
when checking the PJAX live demo - http://padrino-pjax.heroku.com/
The history (back button) don't work!
I can not find any documentation about it, it seems useless if it craps the history functionality.
Can anyone tell me if this is how it should be?
What I did to check was go through the 3 links (don't forget to check the "use PJAX" box)
then clicking back and seeing it went to the first one instead of the second.
thank you
it's works fine. you need to enable it first via checkbox ;)
I suggest to check the original code, what you posted is a porting of the original demo founded here: https://github.com/defunkt/jquery-pjax/tree/heroku
Does watir's browser.text.include? count text inside invisible divs? If so, how to search only for visible text?
I put all the instructions into the html from the beginning and use jQuery to hide and unhide the relevant parts.
How can I use watir's waiter to wait for only text that is visible?
My problem is, that the waiter always returns true, even before I have made visible a certain text.
Don't use Watir's text method. It is very quick and dirty, and has lots of misgivings, many not even related to this issue about visible text. Solid Watir test developers will avoid it. I almost never use it myself, and only when I am doing something extremely quick and dirty. Also, it is implemented differently with different browsers.
Instead you should access the text you care about in terms of the actual element that it is in. You should reference the div or whatever.
What's wrong with:
text_from_all_my_visible_divs = br.div(:id, 'divs I care about').divs.select do |div|
text_i_care_about(div) && div.visible?
end
def text_i_care_about(div)
div.text =~ /regexp/
end
.visible? is in the unit tests, it's official, don't be scared of it :)
Alan
include? sees all text, not just visible text. See WTR-433 ticket for details.
There is Element#visible? method that is not officially supported (as far as I know).
What are you trying to do? If you have a lot of text on the page, and want to show only some of it, you could put the text in a few divs and then see if the div is visible.
while designing my user control, i encountered the following problem:
i would like to set the UserControl.CanGetFocus to false, which is not possible due an error message telling me that a control unable to receive focus can not contain elements who are able to receive focus.
but as i don't want them to actually receive any focus, i would like to disable this for the child-objects as well as for my user control. i can barely believe that there's no possiblity to prevent the child-controls to receive focus, no matter of what type they are? i currently use imageboxes and pictureboxes.
already searched using google, always leading to the result that the property cannot be set to false under these conditions...
If you put the picturebox in a frame and the disable the frame then it will not receive mouse events. Doing this in combination with setting the tabstop to false will prevent the picturebox from receiving focus.
I've used this technique in the past to create a checkbox usercontrol that can be made read-only.
You can set the TabStop property of the childcontrol to False.
Have you tried just using Image controls? If I recall correctly they're lightweight and shouldn't capture focus, whereas a PictureBox is always going to be able (in theory) to capture focus. Depending on your need, this may be sufficient.
Can you set an enabled property to false?
You might want to look at this article.
http://support.microsoft.com/kb/180216
Sounds like you have a problem. The only known workaround is to set the UserControl's Enabled property to False instead of setting the CanGetFocus property. But then, of course you would not be able to respond to clicks and things.
It's been a while, but the solution to this that we used for years was to catch the received-focus event (sorry, can't remember what it is) and then explicitly force th focus to something else. It's kludgey, and not easy (because of the vagaries of event-ordering and reordering in VB/Com Windows), but it got the job done.