Im trying to make apps and always when I set the elements in the xib, it looks fine, then I open the simulator running 6.0 and some elements appear lower than they should, or some are a bit bigger than in the xib.
Why is this? I unchecked the "Use Autolayout" and still it appears in a different way.
Any idea?
Related
We are building a kiosk app and noticing some odd behavior with Google Chrome. To debug, we are monitoring all of the incoming events with monitorEvents(document); through the dev console and noticed 2 different kind of scenarios.
Eventually after a few minutes of heavy multi-finger/gesture use, we are stuck in a touchstart/touchend loop where touchend does not propagate down to a mouse/click event (breaking our app as we only handle onClick). It is continuously stuck in touchstart-touchend-touchstart-touchend for every finger click.
A continuation of scenario 1 with heavier use, we are getting absolutely no events in the console, not even a touchstart.
We are using Chrome 62 with Windows 10 with the following flags:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --kiosk --incognito --disable-pinch --overscroll-history-navigation=0 URL
We have tried to add --touch-events, add --disable-gpu, remove our previous flags, but still facing the same issue. It seems to be an issue between Chrome and Windows as we are able to replicate it on google.com (with getting no events). When we plug in a mouse, we are able to click the buttons so the app is not frozen, we are just not getting any touch events (only mouse works at this point). Touch is still working on the Windows and Chrome App level, just not our app viewport.
The kiosk is a Dell All-in-One machine. Has anyone else experienced this kind of issue?
Thanks!
UPDATE: Using Chrome 68+ I no longer have this issue. I have not tried versions between 62 and 68 to see where it was fixed but I am glad that it is!
It is a little late now, but maybe this will bring some closure. I experienced the same problem and like you, only in Chrome. The best I could determine was that this glitch is dependent on a particular model of touchscreen in the computer.
Check the hardware IDs for the touchscreen in Device Manager. Only the Inspiron 20-3059 models with a touchscreen made by Advanced Silicon (VID_2149&PID_4C39) exhibit this behavior. Other 20-3059 models with a different touchscreen model (VID_0457&PID_1192) work fine.
Oddly enough, later Inspiron 20-3064 models also work fine, though they also had Advanced Silicon touchscreens. The PID was increased to 4C3E so perhaps they discovered this issue and fixed it for the newer model.
I wasn't able to find any combination of driver/firmware/Chrome versions that would fix the problem, but this is as close to a root cause as I could get.
I have a very weird bug that I just can't understand.
I am currently using the WPFMediaKit library in one of my programs.
When using the library in a near empty new "demo" wpf solution, the image from the USB Camera source is rendered perfectly to the MediaCaptureElement class.
However, using a more complex solution, the same library (without changes), the frame gets rendered black. I can see there is connection to the camera and everything goes well, DirectShow graph is built normally and everything just looks fine, besides the black frames. I can even open the camera properties and see it pushing out frames as usual.
Also, this only happens on Dell E6540 (With an AMD and Intel HD gpu) if it's Windows 7. Windows 8/10 work fine. Have tried a lot of drivers nothing seems to change the output.
I have no clue what to do or what to try.
After many hours and just after deciding to post this question, I found the answer.
The more complex solution, under the AMD Settings application was set to use "High Performance" mode, this mode was automatically enabled on Windows 7 for some reason. Disabling that and setting it to "none" or "lower power" fixed the issue.
Doesn't change the fact that there is an issue with laptops with dedicated AMD GPUs, probably something to do with DirectX/Direct3D which is used to render the frames.
TL;DR:
application is built with WPF, running on .Net 3.5
newest and older versions of the app work properly on many different machines
on one specific machine it malfunctions in a strange way:
either does not start, displays black screen instead of "welcome" screen; can't do anything on that black screen
or does start and works properly, until a TextBox is presented and until the user starts entering the text into it; then application immediatelly hangs
Background:
I have built a WPF application on .Net 3.5. I've checked the application on various machines with different OS, ranging from Windows XP up to Windows 7 - and it runs fine, no bugs, etc. It also works fine on my client's several target machines, XP and W7 included again.
However, on one machine, it suddenly ceased to work. My client sent me the machine so I can investigate. From the files on its drives, I can see there were older versions, and they were used by the client for a few months. I also see that the newest version is not installed yet on this machine. So, I tried running the old versions first, to see what's the problem.
What user sees:
oldest versions (say, v1, v2) of the application does not work at all. When they start up, the only thing the application displays is ... absolutely completely black window. There should be a "welcome" screen, composed of few images and labels and a button. The app is not frozen it is "responsive" (Win7 can communicate with it, the window is not dimmed).
last (but not newest, let's name it v3) application runs fine, everything is clickable, features work OK, except one. When user is asked to provide a password, the user is presented with single TextBox in a popup. When the user enters at least one character in that textbox, the application freezes. It freezes even before having rendered the masked '*' of the password. The freezing is total, the application stops responding (the window is dimmed and the OS wants to close it), CPU goes to 100% (actually 50%, two-core system) and the only way to stop is kill it via task manager.
then I installed and tried running the newest version (v4) - it behaves just like v3 above
I've also tried reinstalling all the versions, just to be ensure the .EXE/.DLL files are not damaged - no changes (v1/2 - black, v3/4 - freeze on text)
Technical bits, just FYI:
The app is very simple, one executable with no shared libraries and no shared configuration. There is just no way the newest version could interact with old versions. Seriously, I intentionally made the app in a way it can be "just copied" and several instances can be safely kept in separate folders.
All versions of the app (v4, v3, v2, v1) work properly on all other machines, with various versions of Windows
The problem can't be related to user files or configuration, I tried copying them from problematic machine to healthy ones, and the problem does not repeat
Related to password box: There are absolutely no event handlers in the code that could produce a deadlock or freezing. The password textbox has no text-changed handlers. My code reads the text only after an "OK" button is pressed. The app freezes immediatelly when user enters first character, the
user does not even get a chance to press "OK"
Related to startup: The app does almost nothing on startup. It merely displays some form of a splash/welcome screen. There is no logic there except for a nice UI and one button. The user has no chance of pressing that button. When the app starts, the screen is black and has no contents, not even the splash/welcome image.
Tracing and observations:
I've focused on the TextBox part, since it's more granular.
I've got the app to freeze again, and checked the threads with ProcessHacker.
Except for typical threads, one thread that was sitting and busy-spinning at:
wpfgfx_v0300.dll MilGlyphRun SetGeometryAtRenderTime
wpfgfx_v0300.dll MilGlyphRun SetGeometryAtRenderTime
...
wpfgfx_v0300.dll MilContent DetachFromHWND
That's certainly problem with the WPF layer itself. The DetachFromHWND tells me close to nothing, but MilGlyphRun is surely about the text rendering. It freezes while trying to render the text. I've checked the black-screens on older versions of the applications, but I couldn't catch it, since the apps were not frozen, just black.
So..
I've applied literally all pending updates (like, 150 of them, ~800 Mb, most of them were to the OS and .Net framework)
I've tried reinstalling all video drivers
No changes, still black screen, still freezing.
So, focusing back to the problem. It failed to render a text. Sounds obvious, since it deadlocked when user entered a character into a textbox, but it's damn not obvious! The user was presented with tons of different TextBoxes until he finally got to the PasswordBox. All TextBoxes worked OK, only this one fails. And why old verions of the app display black screen and the new version displays the "welcome" screen properly? How can be those issues related?
The connection is: Windows Presentation Foundation Font Cache service.
Sources:
http://support.microsoft.com/kb/937135
http://social.msdn.microsoft.com/Forums/vstudio/en-US/7cc032c1-5f4d-4518-adc6-f53afd051e6b/presentationhostexe-running-at-50-cpu?forum=wpf
WPF uses a Font-Cache service, running as a separate process, for, well, caching fonts. Whenever your WPF app needs to draw some text, it might ask the cache service for fonts. Once in a while the font cache might get corrupted and it then will/may randomly impact any WPF application.
Unfortunatelly, restarting the service is not enough. When this happens, you must delete all FontCache files that this service keeps on the disk. Before deleting them, you must stop the "Windows Presentation Foundation Font Cache service (or whatever it's called in your languge, for example Usługa buforowania czcionek platformy Windows Presentation Foundation in Polish..). Then, go to
Win7: %systemdrive%\Windows\ServiceProfiles\LocalService\AppData\Local\
Vista: %systemdrive%\Windows\ServiceProfiles\LocalService\AppData\Local\
WinXP: %systemdrive%\Documents and Settings\LocalService\Local Settings\Application Data
and remove all files looking like FontCache.dat. The source articles mentioned only one file (FontCache3.0.0.0.dat, but in my case there were around 8 files with similar naming convention).
After deleing them and restarting the service, all versions of my application were running properly again. No black screens, no freezing on textbox.
I am trying White for the first time. I tried to run a sample test to get a window of notepad, it doesnt seem to work. Here is what I did:
//Launch the app
Application app = Application.Launch("notepad.exe");
//Get the main window after launching the app
Window win = app.GetWindow("Untitled - Notepad");
This last line throws an error as type initializer exception. When I go into the source code for White, it fails at finding the window.
When I used GetWindows() and try to get first window, it works fine.
But the same error is thrown for the child objects as well.
I have Win7, 32 bit. By build configuration is Debug|x86. I also tried the same code on Win XP, 32 bit and it worked well.
Can anyone please tell me how do I go about this.
I think I found the solution. When I tried running same code on a Win 7, 64 bit machine, it seemed to work perfectly alright.
I tried using the dependency walker and found that there is some issue with the dlls on my machine. Though I dont think I can get my system fixed just for that, I guess it might help others if they are facing this issue.
First I'd like to head off the "wait a minute" questions.
Yes, I've read every thread with similar titles and subjects on SO and beyond.
Yes, I'm using the very latest version of SP1 and any potential hotfixes that might be related to this problem.
So, with specificity, here is my problem:
When I'm debugging Silverlight applications and it hits a breakpoint, everything works just fine as long as I use the mouse. I can continue, step, stop debugging, disable and enable breakpoints all just fine -- as long as I do so with the mouse.
But when I use the keyboard, Visual Studio freezes for a number of seconds, sometimes over a minute. This is any use of the keyboard. But after a short time, it starts to work just fine until that debugging session is over. But the next debugging session (regardless of whether I use the same instance of Casini or not) it will do exactly the same thing.
When I say any keyboard use, I mean it. F5 (Continue), Shift-F5 (Stop Debugging), F10 (Step Over), as well as typing in the Immediate window or even hitting the ALT key to highlight the menu.
For instance, if I try to type something in the Immediate window, it freezes for about 15 seconds and then shows the first key and repeats the pattern about 5 times until it releases and everything is just fine.
When I say "freezes" I'm not talking just Visual Studio but it hangs the entire operating system except for my ability to move the mouse. Even so, the mouse cursor remains what it was when it froze regardless of the program it's over, such as the text selector.
It only happens with Silverlight and it doesn't matter which version I use.
Here's what I'm running:
Windows 7 Professional 64-bit, all of the latest updates included, 12 GB RAM & 1.5 TB HD.
Visual Studio 2010 Ultimate with all of the latest updates.
All software is legit and I've already tried removing and/or disabling just about everything that can be removed or disabled, including extensions. I've used Process Explorer from Sysinternals to kill or stop everything I can. I've also tried it on a very simple Silverlight application with nothing more than one line of code that doesn't access anything.
EDIT: Forgot to mention that I also don't have it loading symbols beyond the "Just My Code" that it normally would and I've tried every debug setting that I can think of as well. And Intellitrace is also turned off (since I do have Ultimate), but that makes no difference either.
UPDATE (11/18): It gets more and more odd. I determined that the temporary freeze doesn't occur only when Visual Studio has focus. When VS (during the super-simple Silverlight app) goes into debug mode, any keyboard access AT ALL causes the same effect. SO, it appears that it has to (in some way) be related (at least in part) to my Windows setup, contrary to my assertion in the comments, but I cannot possibly fathom how. And if other programs are doing something when it freezes, the delay is longer (which makes a certain amount of sense with the symptoms). I'm still at a complete loss.
Anyone have any ideas or see this before? It's really frustrating.
I solved the problem.
It turned out to be the LastPass toolbar. It's a very handy thing and I've used it for years without issue. Yeah, yeah, toolbars are evil, I get it. :)
Disabling it in IE fixed the problem completely. I can still use it in FF (which is my main browser anyway except for working for which I use IE) and everything works fine.
Even so, it's bizarre to me that the toolbar would only have an effect when SL debugs. I didn't have an issue with ASP.Net debugging and I didn't any issues when the SL app was actually running, only when I hit a breakpoint AND hit a key within the first 15 seconds or so.
In any case, problem solved and thanks for your suggestions.
Try changing registry setting LowLevelHooksTimeout from 5000 to something low, like 300.
It can be at
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\Control Panel\Desktop
or
HKEY_CURRENT_USER\Control Panel\Desktop
(first setting at Policy key seems to globally override user setting).