Focus behaviour AR8.1.1 versus AR7.0.9

I've observed a difference in focus behaviour between Linux R8.1.1
and Linux AR7.0.9 and I'm wondering whether it is a bug or a deliberate
change in policy. The difference is as follows.
I launch AR on a document that has a /Widget annotation
with a /U event, any widget will do. I then click on the /Widget
so that it receives the input focus. After which, I obscure
part of the AR window with a terminal window,
and then I move the mouse from the terminal window back
to the AR window.
With AR8.1.1 I observe that the AR window is automatically raised.
This is very odd as my KDE setup requires a click to raise a window.
Therefore it would seem that AR is implementing its own window
raise. I do have focus follows mouse, but irrespective of
my window manager settings, AR 8.1.1 raises itself
whereas AR7.0.9 does not. I've also been able to reproduce
the difference with MWM and so I'm a bit perplexed.
Has anyone else noticed this behaviour? As I said at the beginning
of this note, I observe the difference for any PDF with a /Widget
i.e. it is not specific to something I'm doing.
James Quirk
p.s. Going off on a tangent, I'm now wondering if this autoraising
is responsible for the difference in refresh rates, between AR8.1.1
and AR7.0.9, that I've reported elsewhere on this forum.
I've also noticed that in some /Widget-heavy documents there is
considerable blinking with AR8.1.1 when the document loads
whereas with AR7.0.9 the PDF loads smoothly. Thus is would
appear that unnecessary refreshes are occuring as the
document is rendered. Again I'm wondering if the autoraise
issue is involved.

The file:
http://www.amrita-cfd.org/4adobe/screen-refresh/test1.pdf
is as good as any for showing the focus difference
I describe above. It also shows the problem with blinking.
When the document loads, click on the "continue reading" button
to get past the cover sheet. Then click the ">>" button and
follow the steps I outline above.
James

Similar Messages

Focus behaviour on E17

Hi, is there any way to change the focus behaviour in E17?, I would like to use "click to focus"

Cam wrote:Be careful, I used E17 for a while and then went back to fluxbox, I had to click the windows to focus them again it felt weird
Yep, but i've been using E17 for a couple of months and it's unstable but usable.
Thanxs for the replay by the way

Browser window focus behaviour

Hey all, I am not sure if this is the most correct form for this, so feel free to let me know if there is a more appropiate one....
Within my organization, Sun Java is really causing a lot of frustration with how some of our web pages are working. The scenario is this...
1) user views details regarding a specific issue on a web page
2) user enters some data in textbox and then clicks button to email someone else
3) pop-up is displayed for the user to enter data for email
4) original page 'reloads' itself, which Sun Java then seems to cause it to steal focus again.
5) user thinks email window is gone, even though it has only moved behind original window.
Sometimes it takes a couple of seconds for the original window to steal the focus back, it there is a lot of data to display, so the user could already be typing in things, and then have a different window take focus.
We need to maintain some sort of 'reload' on the original page, in case any data changed on the page before the user clicked on the 'email' button, or other buttons, etc.
Our users are VERY annoyed by this. If we turn off Sun Java and use the MS jvm, it works fine. For some web apps, we need Sun Java though.
Users are on a variety of Sun Java versions, 1.41 to 1.5. at the least.
Any ideas on how I can change this behaviour?
Thanks,
Craig

I think that that's just the nature of the food-chain. It works much the same way that the browser's document window loses its ability to trap an event if that very same event is being trapped by an applet contained in the browser's window. I suspect that while you cannot programmatically give focus to the terminal emulation panel, it is possible for the user to click and give focus to the panel. What you might want to do is to create a popup that doesn't require a user's response.
V.V.

Strange focus behaviour

Every once in awhile (completely unreproduceable), some fields in my app will lose focus while typing in them. For example, I'll type a character, the field will lose focus, click on field again, type another character, lose focus, click on field again, ...
I have no code executing on focus events such as focusLost(). I have been unable to see if the problem only happens in fields I have overridden. For example, I have a JIPField class that extends JTextField and only allows valid ip addresses to be typed in. The only time it has happend to me was while typing in this field.
I'm posting this in the hope that someone else out there has experienced this or has any ideas on how to fix it or even track it down.
Collin

Sorry for my late reply. The class is using a PlainDocument to validate the IP. The insertString and remove functions (of it's parent AbstractDocument class) have the code which verifies the text being typed is valid. Again, there is nothing in the classes which touches the focus so it is quite weird.
During validation, if the user types something invalid the insertString function gets called and validates the new text. If it is valid the function allows the insertion of the string otherwise it doesn't and 'beeps'. That's all that happens so you can see why I'm so confused.

Focus behaviour and shortcuts

I wonder if in flex UI is possible to change bahaviour for
losign focus ?
I mean i want changing tab with enter for some controls and
even in a table when i hit enter to go on the next editable cell in
the same row.
Also how can i attach shortcuts to buttons ?

Hi,
Please try handling keyDown and keyUp events. Please find
more details at the URL below.
http://livedocs.adobe.com/flex/3/langref/flash/display/InteractiveObject.html#event:keyDow n
Hope this helps.

Forms 11g focus behaviour

Hi...
In forms 10g when we click a text-item the text of that field is automatically selected. In 11g that does not happen. Is this a bug or what?
Regards
Ricardo

Due to customer complaints one way or another, this behavior has changed several times over the years. If you want to ensure that all text is selected upon entry, create a WHEN-NEW-ITEM-INSTANCE trigger and add this code:
SELECT_ALL;

AIR/Windows 7 Onscreen Keyboard

Hi
Any reason why the onscreen keyboard would stop working when a TextInput is being focused?
* AIR 2.03
* Flex SDK 3.4
* j3500 Motion Computing tablet (http://www.motioncomputing.com.au/products/tablet_pc_J35.asp)
The onscreen keyboard is the default version that comes with windows 7 Professional...The interesting thing is we did not have this issue in the AIR app in the past up until the our latest app update.
There are no definatley no programmical modifications to the default focus behaviour of any text editable fields or anything that would interrupt the default behaviour of the flash/air integration with the onscreen keyboard and the operating system....it should be transparent AIR/Windows 7 function and totally out of our hands...
The soft keyboard will still enter text into input fields, however the keyboard needs to be manually opened. The standard behaviour was...when the wacom pen tapped into a text input, a keyboard icon would appear next to the input and open the keyboard over the AIR app, now that does not work..
We are really at a lose with this issue and need to know which direction to look into. The tablet has all windows and motion computing specific updates applied to it...and can be replicated on other tablets etc..
We have not tried linux or mac installations troubleshooting because do not have direct access.
Any ideas much appreciated.

I am havin the sam eissue as you can tell I have set al setings to fast..and still it skips keys randomly. I have reinstalled drivers and what else can I do? This keyboard came with bundle HP Pavilion s5310f. I need a fix for this issue. I type for a living and this is unacceptble sppeed and tuypps...shew. Any info, help, or new keyboard appreciatd...thisis no working

Any tiling wm in C++ ?

hi all , i would like to know if there is any tiling wm written in C++ ( maybe you don't like that , " What about C ! " or " C++ is C " ) as i have ran into many people considering that C++ is crap and C is superior , but i would like to use a C++ wm and try to help extending it or at least playing with it
hmm , dwm is nice and simple and iam using it atm

l3thal wrote:
well , i don't want to make one from scratch , as i don't have the time for that , also i want something realible to use not just my own hacks or whatever , but thanks for the link
i can see its really a good start " It is only around 50 lines of C "
also a wm in C or C++ makes me happy and confident somhow ( thats why iam using dwm atm )
Most wm's are C/C++...
Why do you want to hack the wm itself anyway? sense of power? I don't get it.
If you want to dev for WM's just start writing patches for an existing WM...it doesn't have to be C++, pretty sure a C++ coder could handle C without major changes in logic.
OR write stuff to aid WM's like useful applications etc.
PS Since you're a DWM user why not hack your way into that? Add stuff that you need. Just adding stuff that you can "see" doesn't mean it's something useful (unless you make it be useful ). I made DWM have click to focus behaviour instead of selecting windows as you walk over them. Really simple hack too (only one line changed). See if you can spot what that line is. Consider it homework
Last edited by Wra!th (2009-04-15 18:48:17)

When i placed a AccessKey to Submit Button (Eg: AccessKey="S"), and pressed Shift + Alt + S, the focus is going to Submit button and as well as Submit operation is also performed. Is this the expected behaviour in FireFox for AccessKeys

When i placed a AccessKey to Submit Button (Eg: AccessKey="S"), and pressed Shift + Alt + S, the focus is going to Submit button and as well as Submit operation is also performed. Is this the expected behaviour in FireFox for AccessKeys

What were you expecting when using an accesskey?
I use that also on this forum to submit my posts:
<pre><nowiki><input accesskey="s" class="btn btn-important" value="Post Reply" type="submit">
</nowiki></pre>

Weird behaviour - logged in twice? black squares around focused objects?

Someone else was using my laptop yesterday at work and now I'm getting some odd behaviour. Functionally, everything seems to be okay, but there is a solid black square around GUI interface objects that I focus on in the OS. And clicking on the apple menu lists two instances of Log Out username, Restart, and Shut Down.
I tried repairing permissions and keychain access but I don't even know what to attribute this behaviour to.
Any help would be much appreciated..
Thanks in advance,
Matt

Matt
Welcome to Apple Discussions!!
Go to System Preferences > Universal Access and check the "VoiceOver" and other settings. You may need to set everything back to default to get rid of the black square.
Not sure about the doubled menu items …

Not user friendly behaviour for CNiNumEdit control when it has got a focus

The CNiNumEdit hasn't user friendly behaviour when it has got a focus on TAB event for example.
If you set a value in your prgram like this code:
m_ninumedit.SetValue ( 1234 );
and the focus is on other control and then you press TAB for changing the focus and the control m_ninumedit got it but it put the edit cursor in front of the first character '1'.
The correct behaviour would be that the control selects all characters to be ready to edit a new value.
The later versions that 7.1.0.313 have a bad behaviour (cwui.ocx)

Hello Benjamin,
You will find the sources code to test the behavior of CNiNumEdit by using the TAB key between two controls CNiNumEdit.
Best regards
Armageddon
Attachments:
TestCNiNumEdit.zip ‏510 KB

GridView focus/selection behaviour

A am writing a WinRT application which utilises a Gridview to display some data. The Gridview has a SelectionMode of Extended so that as the user navigates the grid with the cursor keys the selected item moves with them (plus I have multi-select functionality)
The problem I'm experiencing is that if you navigate the grid using the cursor keys and have Ctrl pressed down, the selected item remains where is was and only the focus changes. My DataTemplate doesn't show the focused item so it's quite confusing
to the user.
Is there anyway I can change this behaviour so that navigating the grid with Ctrl held down works in the same way as if it wasn't being held down?

The answer was quite simple in the end. Just add a GotFocus handler like this one:
private void SdxGridView_GotFocus(object sender, RoutedEventArgs e)
if (e.OriginalSource is GridViewItem && !((GridViewItem)e.OriginalSource).IsSelected)
SelectedItems.Clear();
((GridViewItem)e.OriginalSource).IsSelected = true;

Lousy publish behaviour - focus stealing

While editing, ical will automatically update a published callendar. Unfortunately it randomly resets user input focus throwing my editing task into disarray, and this time ical crashed (race-condition?).
Is anyone else running into this focus-stealing behaviour?
Could the developers look into a non-intrusive way of publishing and syncing iCal? Maybe build-in better use of CalendarStore.framework for iCal? If necessary upgrade it to manage publishing calendars. Then my apps would automatically benefit. Push notifications via MobileMe, exchange, and others would work better too.

Try this: When you are in the window you wish to be "pinned", eg; not go away when you click elsewhere, right click on the tab representing that window, and click on "pin as App tab". Can also be abbreviated as alt-p WITHOUT hitting the tab, as long as you are inside the window you wish to preserve.
This appears to solve the "steal focus" issue, I hope it is useful to you wrt your problem.

Unwanted Android selection behaviour... different in Flex versus pure ActionScript... Why?

Hi,
I'm trying to get to the bottom of the text selection behaviour on my Android Xoom under different circumstances:
1. In a pure ActionScript mobile app, selection and copy / paste is controlled through a floating control that appears on screen without resizing or otherwise moving anything
2. In a Flex mobile app, selection and copy / paste is controlled through a UI bar that appears at the top of the screen, pushing the entire app downwards, losing focus on my textfield, ballsing up every bit of control I have in addition to confusing the hell out of my user whose finger is no longer pointing at the piece of text they wanted to select but rather at something else that is about a half-inch above that point...
So...
Obviously, I want to get to 1. for Flex - eg: I want to allow selection and copy / paste without loss of focus, without repositioning and without confusing the hell out of my user.
Does anybody have any clues how I can achieve this?
Thanks,
G

Got it. The two selection behaviours depend on the underlying skin.
This one works with Flex:
skinClass
: ClassReference("spark.skins.mobile.TextInputSkin"
Where this one shifts the app down, places a bar above, and generally screws with any interactivity you may have wanted to do using your selected text...
skinClass: ClassReference("spark.skins.mobile.StageTextAreaSkin"
G

Behaviour sRGB embedded pictures in Lightroom versus IE

hello,
I have a calibrated monitor (6500K and a gamma of 2,2). I'm working with Windows Vista. When I view a picture with embedded sRGB profile in InternetExplorer (uses no colormanagement) and Adobe Lightroom (uses colormanagement), there is a very little difference in color between Internet Explorer and Lightroom or Windows photo gallery. IE shows the colors a little bit more saturated. The grays look the same.
I know that when I view a picture with embedded Adobe RGB profile or Prophoto profile, It will look completely different in Lightroom versus Internet Explorer.
sRGB is the default color space for Windows IE. Is it normal, even with a calibrated monitor, that there is still a little difference visible with sRGB embedded pictures, between applications using profiles (like Lightroom) and applications not using profiles (like Internet Explorer)

>s it normal, even with a calibrated monitor, that there is still a little difference visible with sRGB embedded pictures, between applications using profiles (like Lightroom) and applications not using profiles (like Internet Explorer)
Yes. You will only see the correct color in managed apps even on calibrated monitors. This includes Safari and Firefox
with the secret setting, but excludes Internet explorer and very surprisingly Google's Chrome (Boooo Google!!!). The reason for this is that the color primaries (i.e. the actual colors of your monitor's red, green, and blue emitters) are never exactly the same as sRGB's.
There is also a small knee in the shadow portion of sRGB. Most calibration software will calibrate not to this tone curve, but to simple gamma 2.2, so you will always see a small difference in the shadow portion between managed apps and unmanaged apps.
Now as Sean notes, you cannot really predict what your image will look like on other people's monitors. In general it will hover around to the look of sRGB on your calibrated monitor in managed apps, which is why everybody will recommend sRGB. But individually, you can get quite large deviations. Especially because of the current prevalence of laptops, which without fail almost always have terrible screens. They usually give rise to very strong shifts of the blue component (which some people erroneously interpret as a problem with sRGB). Unfortunately there is really nothing you can do about it.

Focus behaviour AR8.1.1 versus AR7.0.9

Similar Messages

Maybe you are looking for