look this playground example
When tabs are re-created, it steals focus to the text field. Is it a relevant behavior ?
This is a bug caused by the tabview's current tab being changed programmatically. It's fixed in this PR https://github.com/qooxdoo/qooxdoo/pull/9117
Related
I have a toolbar item implemented in Xamarin Forms project in xaml like this.
<ContentPage.ToolbarItems>
<ToolbarItem Name="Create" Command="{Binding AddNewCabin}" Text="Add Cabin" ></ToolbarItem>
</ContentPage.ToolbarItems>
The command AddNewCabin is binded to a navigation method.
When I come back from the next page the text for the tool bar item is paled out like a visited link. I have no idea how to turn off that kind of behavoiur.
I thought that was an issue with a click event however I tried binding the click or the command to an empty method and the text is not paled out. It is only paled out if there is some Push navigation that occurs afterwards using this event.
I have also tried navigating using other events on the same page from listview for example and in that case the toolbar item is also NOT paled out.
So the only occasion when it is paled out (changes color) is when I navigate using the commnd or event binding of the toolbar item. In all other cases this doesn't occur and I have no idea why. Does anybody know? Thanks.
PS. I Aam testing in IOs.
Sadly, I cannot reproduce behavior of your toolbar item. On my machine navigating from toolbar item works perfectly. Check my gif. Colors of button "Add" are switching properly.
You should try removing and adding your button on the OnAppearing event.
But this is very strange behavior. Can you post more code of your implementation?
I'm building an iOS app that uses a webview in one place. When the user taps on an textarea and the keyboard appears the textarea get a shadowing highlight effect and then goes back to normal. Please note that I'm not talking about webkit-appearance och outline, but the shadow that covers the whole textarea being tapped.
I'm guessing this is some kind of accessibility feature. Still, it mess up my animation and makes the whole view look like crap.
Does anyone know if it's possible to remove this highlight shadow?
You can disable it by setting the css attribute -webkit-tap-highlight-color to rgba(0,0,0,0);
But as you mentioned it is a usability feature, so you should not turn it off. ;)
See:
http://www.yuiblog.com/blog/2010/10/01/quick-tip-customizing-the-mobile-safari-tap-highlight-color/
I'm a newbe for Blackberry and finding it quite difficult, I'm working on the TabControl example. I have changed the tabs to scroll. Now when i scroll through tabs the focus changes and as soon as the focus shifts to the other tab, the data for that tab appears.
I want to make these tabs clickable only, though they shall scroll but should change only on click.
And also when i use UIApplication.getApplication.pushScreen(someScreen) in the tabs, this someScreen appears out of the tabs, whereas i want to show this screen below the tabs only.
please help
You have to override onFocus(int) to not do anything when focus is moved. (You may or may not have to override touchEvent to handle an actual CLICK event).
You can push a screen into tabs that is not part of the tabs already. If you want something new to appear, try switching managers within the screen instead.
The problem happens only in IE7:
When I go to the next tab some elements (text input fields, buttons) from the previous tab are not completely 'hidden' and shown on the next tab (just on top of it). Buttons disappear when I mouse over them, but text inputs stay there forever.
I am using jQuery 1.4 and JqueryUI 1.8
Has anyone seen that problem before?
Thanks
i faced the same problem before. My advice - begin with empty tabs, then add step-by-step all elements to their tab-containers. one of them is parsed incorrectly by ie.
I have a textbox that I am attaching jQuery UI's Autocomplete functionality to and I am using CSS to give it a max height via the example here. My problem is that doing this causes the z-index problem that bgiframe solves to come back again, but in a different way. The initial autocomplete menu is above all the controls underneath it, but when I begin to scroll the autocomplete menu falls behind them.
Any suggestions?
EDIT:
This is purely an IE6 bug.
As you can see, after scrolling down the autocomplete falls behind the other controls.
I could solve the problem by replacing offsetHeight by scrollHeight in the following line (from jquery.bgiframe.js) :
height:'+(s.height=='auto'?'expression(this.parentNode.offsetHeight+\'px\')':prop(s.height))+';'+
This change solved the bug for the autocomplete fields with vertical scrollbars. I could not spot any regression in other kinds of dialogs (but I did not run extensive tests).
You need to reverse the z-index order of the form elements (or their containers) using javascript. I.e., "Social Worker" has the lowest, "DX Code" the highest z-index.
You could change the offsetHeight to scrollHeight, like Siggen says, but I have encountered problems when there is only 1 result returned from the autocomplete. The 1 result is squished into a window that only like 2 pxs high.
I found a fix though.
When you have a data.length<2, you should use the offsetHeight, rather than the scrollHeight.
You have to modify autocomplete.js.
Locate this code:
if($.fn.bgiframe)list.bgiframe();
And make it this:
if($.fn.bgiframe){
if(data.length<2)
list.bgiframe({height:'expression(this.parentNode.offsetHeight+\'px\')'});
else
list.bgiframe();
}
Remember, this code should be used in combination with Siggen's fix.
I have used a combination of both parameter for the height like this:
'height:'+(s.height=='auto'?'expression(Math.max(this.parentNode.offsetHeight,this.parentNode.scrollHeight)+\'px\')':prop(s.height))+';'
Look at the max function. Now it is good with no scroll bar (shorter list and longer list as well)
and now the autocomplete component looks perfect in IE6.