When I click the menu button, no menu appears.
Google Chrome just updated on my machine to the latest version (Version 55.0.2883.87 m), and after the update my qx.ui.form.MenuButton stopped working. Is there a patch or workaround for this? I'm on a Windows 7 machine.
It even fails on the demobrowser:
http://www.qooxdoo.org/5.0.1/demobrowser/#widget~Menu.html
This is because Chrome introduced in version 55 pointer events: https://developers.google.com/web/updates/2016/10/pointer-events
qooxdoo already had a pointer event layer which created artificial events for browsers not supporting pointer events natively. This layer didn't detect chromes new native pointer event support, leading to double fired ponter events, which leads to menu button menues being opened and closed right afterwards with no visible reaction to the user.
This was fixed in qooxdoo github master via PR https://github.com/qooxdoo/qooxdoo/pull/9219
Please also note how this could be fixed for existing qooxdoo 5.0.1 applications: https://github.com/qooxdoo/qooxdoo/issues/9182#issuecomment-265161921
Or you could use current master or patch your local copy manually using the code from https://github.com/qooxdoo/qooxdoo/pull/9219
They released a new Update since 3 Days. Here you can get it.
Related
My app written with Codename One involves showing a camera preview In a main form. I have used the native interface implementation to make it work on Android (iOS later).
The app also includes in app purchase to upgrade to full version. That's why a form is shown regularly to suggest the user to upgrade. They can also choose to upgrade later which causes this upgrade to full version form to disappear and make the main form with the camera preview to appear.
Yet on real devices sometimes the upgrade to full version form does not completely disappears and there are reminiscences of it on the main form. In that case the camera preview is displayed on part of the screen and the app buttons do not show. However after some seconds if the user touch the screen the main form gets completely shown and the reminiscence of upgrade form are gone.
It looks like there may be too much things done on the UI thread but I am just calling new MainForm(theme).show() when the user hits the button to close the upgrade form. So this should be OK shouldn't it? Please note that the CN1 simulator does not show edt violation (but there is no camera preview in the simulator).
Or do I have to call revalidate () in the MainForm after adding the components into the layout ? What should I do actually to make these reminiscences disappear ?
Any help really appreciated,
These things are always hard to track but I'm guessing the peer component collides in some way with the new form.
Make sure you don't call postInvalidate unless you really have to and even then you should generally limit and avoid it when possible as it might conflict with our drawing logic.
Also make sure you didn't change the opacity of the parent forms e.g. if you changed the form UIID.
It looks like the solution has been found. Indeed I had a native method that initialized the camera and the surfaceview. I was running this method on the EDT and then showing the new MainForm.
Indeed I embraced the initialization method in an invokeAndBlock() block. Now it looks like the kind of lag is far less visible (I could not see it). In my own logic I can explain it with the fact that the invokeAndBlock() will do the initialization job on a separate thread and when it's fully ready (so the camera and surfaceview are ready to be shown), the MainForm can be shown.
Could it be the actual solution #Shai ?
I'm trying to use MS UI Automation to test a WPF application, and am using the Inspect Object tool (inspect.exe) included with the Windows SDK to look up the AutomationId property on certain elements.
Inspect is behaving very strangely for me:
If I close all applications and start the WPF application and Inspect, inspect is able to see the AutomationId property for various UI elements. Elements which do not have an AutomationId simply show two quotation marks denoting an empty string ("").
After I perform a few actions in the WPF application, inspect.exe hangs and I have to kill it and restart it. Even though the machine's CPU and RAM utilization are around 50% or less, I've tried waiting several minutes--possibly close to 20 or 30 mins on a couple occasions--to no avail.
After restarting, inspect.exe can no longer find an AutomationId for any UI element, even those which did have them previously. What's more, the property is completely missing when hovering the mouse over the WPF application--it is no longer listed at all, not even with an empty string value.
If I move the mouse to another screen (specifically, to another computer, using Mouse Without Borders), the AutomationId property reappears with a value of "FormDot"
If I restart only inspect additional times while the WPF application is still running, inspect still behaves the same as after the first restart.
If I restart only the WPF app while inspect is still running, inspect still behaves the same as after its first restart.
If I close both inspect and the WPF app, then start inspect, then start the WPF app, everything works correctly for a while and inspect finds the AutomationId on a few elements in the WPF app...up until the point at which inspect hangs again.
I've tried running inspect both normally and as an administrator as suggested in https://stackoverflow.com/a/7833728/44737, and it behaves the same either way.
What, if anything, am I doing wrong? Am I just too impatient and do I need to wait a really long time instead of assuming inspect is hung? And why does inspect's behavior regarding AutomationId vary?
There are more than one version of Inspect.exe. The latest to my knowledge is the one dated from 2012 that says version 7.2.0.0 in the help/about dialog box.
The old one doesn't have a tree view on the left with all detected automation elements displayed in a tree, so it's easy to check you're using the right one.
The latest one works quite correctly, however, IMHO, the best tool so far to work with UI Automation is Visual UI Automation Verify. It's a .NET program, and he source is available here:
UI Automation Verify (UIA Verify) Test Automation Framework.
Note that although it's a .NET program, it doesn't use the standard .NET automation dlls (more on that here: What's the difference of UISpy.exe and Inspect.exe? (From Microsoft Windows SDK)).
About the AutomationId property, to clarify my initial comment to the question, I meant its usefulness depends on the program that you're trying to automate.
If you own it as a developer, it's clearly interesting. For example, if you're working with WPF, you can use the x:Uid property, it's clearly meant for UI automation. In the Winforms space, it's also quite useful because UI Automation will use the control's AccessibleName by default and revert to the Name as a fallback, for the AutomationId value.
But there are many apps that don't rely on .NET (browsers, native apps, etc.) Usually, for these apps, it's easier to use other properties.
I have been using inspect.exe for a while on a Microsoft Surface Studio PC (running Windows 10), and my experience is that inspect.exe will hang much more frequently (sometimes always) when Windows Updates are pending. When the updates are out of the way, inspect.exe is still somewhat slow, but much more stable.
I made an App on WP7 that uses the textbox for the user to write into, but when the user goes to other app and returns back using multitasking all the stuff in the textbox just gets erased. (The video of the app is HERE what I mean is at 1:57)
The app is already in the marketplace, and I don't want to update it with a Mango version so people in NoDo still be able to use it, yet, I still want to solve that problem, what can I do about it?
you need to persist the textbox value in a setting/file on the device. You can do this manually by writing lots of code to save and restore the values... or you could use the tombstone helper library which will do it for you:
http://tombstonehelper.codeplex.com/
Firstly, the marketplace now supports versions of apps that support both 7.0 and 7.5. See the announcement at http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/10/18/marketplace-comes-to-china-amp-india-also-improves-search-and-7-0-amp-7-5-app-update-options.aspx
In terms of preserving the content of the textbox see:
Execution Model Overview for Windows Phone
and How to: Preserve and Restore Page State for Windows Phone
Here is the new WP7.1 mango Tombstoning examples and tutorial for absolute beginner to tombstoning.
Mango WP7.1 Tombstoning
Hope this helps.
I'm trying to use an existing internal WPF application (I do have access to the source), but it was developed on XP and I'm using Windows7 64-bit.
When I click (for instance) the File menu, 90% of the time I see no drop-down menu at all. The menu still exists - I can use the arrow keys to navigate up and down and choose an option if I happen to know the order of the options, but nothing renders at all.
The other 10% of the time, the menu or some portion of it DOES render, but as I move the cursor up and down I get graphical corruption or disappearing options until I end up back at the "no menu is visible at all" state.
This is also true of combo boxes within the application - they show no data when I drop them down, but I can arrow down and choose an entry.
Microsoft has some advice about WPF rendering issues here but none of these steps has helped with my issue.
Edit: a coworker running Windows 7 sees the menus just fine... he has a different video card, so I'm curious whether this is video-card specific.
This also sounds similar to an issue we had seen in XP, where comboboxes (or menus) would not display properly some of the time. There is a Microsoft hotfix (for at least one flavor of it) here, but unfortunately it is for XP and WS2003. I'm not sure if this could point you in the right direction.
The link to this hotfix was found in this MSDN thread. I am not the author of this particular link, although I do remember raising this issue some time (and a different job) ago.
It turns out that in this specific case, the issue is only present on boxes that have a GeForce 6800 video card. Updating drivers has no effect, but switching to a 7800 makes the issue go away.
I have no idea why this is the case, and I haven't found any information online about 6800-specific graphical issues in Win7 64, but our testing and experimentation shows this is the factor that causes it.
Crazy.
See this question. It's probably a problem with a DropShadowEffect, removing the Effect should fix the problem.
I second that the issue is related to NVidia Windows 7 x64 drivers. Recently I had to replace my video card. Now I have Quadro FX 3400 with the latest drivers and am seeing similar behavior. WPF ComboBoxes don't render dropdown portions. I can only switch values with keyboard after a few attempts. It could be Direct2D-related issue. I also had to turn that off for Firefox to start working again.
It seems like a common question on Google, but I couldn't find a satisfactory answer (unless the answer is 'no')
I would like to add menu items or show a custom menu when a user right-clicks on my Silverlight app.
The closest thing that I found catches the context menu in IE, but not in Firefox, and Chrome shows the context menu and then shows the custom event.
(The tutorial I mentioned was here
http://silverlight.net/blogs/msnow/archive/2008/07/01/tip-of-the-day-14-how-to-right-click-on-a-silverlight-application.aspx)
Here you have an implementation but it's CTRL+Left click, then you get a context menu (about the text, sorry it's in spanish):
http://www.albloguera.es/?p=29
Another option, is the one pointed out do it via javascript, quite chunky solution, and not sure if now it's working in the current 2.0 version :-(.
Good Luck
Braulio
There is no way to do this natively in Silverlight.
I believe that the Telerik control noted elsewhere uses the HtmlBridge to intercept the context click, then draw their own menu, however it does not appear to be working with Silverlight 2.0.40115 now, so maybe Microsoft have closed that gap.
Having no right click is a design decision based on security concerns, rather than a technical one. However I believe that the Microsoft team are considering allowing context menu's in future versions (perhaps even v3)
I've come to the conclusion that it seems it is possible based on my use of Telerik's context menu which works fine on IE, Chrome and Firefox.
Check it out, http://demos.telerik.com/silverlight/#ContextMenu/FirstLook