It not just my curiosity, recently I've received a bugreport concerning one of my AS3 applications. This bug can be reproduced only if the quality in flash player is set to LOW (HIGH/MEDIUM - everything is ok). The bug changes the application behaviour, but it's a mystery for me, why it happens only for LOW quality while quality is said to influence rendering and visual appearance, not the code or behaviour.
Briefly, I have a menu panel (MovieClip) with several items (also MovieClips). Very simple, it appears on a screen after a MouseEvent and a user moves a cursor from one element down to another. When the cursor reaches the edge of the second item, the menu suddenly disappears.
In my code panel hiding is set on mouse click or mouse out.
Personally, I think, that the problem is in Tweener, I have to use that old piece of code. The menu panel is shown when mouse is above a user icon, and concurrently with the help of Tweener I produce some simple effects on this icon.
I have explored adobe and firefox (my app is for web browsers and the bug is reported for firefox) bugtrackers, but so far I have found nothing. Maybe misbehaviour of flash player 11 with Arrays, already fixed... I've run out of ideas.
From the docs:
LOW
Specifies low rendering quality: graphics are not anti-aliased, and bitmaps are not smoothed.
If it only happens when rendering it set to low, then it's probably a timing issue - i.e., the bug has always been there, but because you're wrapping up rendering earlier, you can trigger then bug. Is the bug reporter's computer a slow one? Is there a lot happening at once? Is the menu being removed, set to invisible, or repositioned?
Like #jeremynealbrown said, try and separate out your class to a simple project to make sure there's nothing wrong with your logic there.
Another method, override the removeChild() method, and visible and x and y properties to see which one is setting it, then put traces before all calls that call these to see what's triggering it.
If you think the problem is in Tweener, add a MOUSE_OVER listener to the menu panel that calls something like removeAllTweens(), no matter the state of the menu panel. If the bug doesn't happen anymore, this will show you that it's related to the tween engine.
Related
I have investigated this problem across some different computers with theming/classic-theme and/or theme support disabled in my app...
Problem when Windows is configured to draw the window while dragged + theme drawing enabled:
My primary app window stutters greatly when dragged around screen. It is even so bad that if I drag the window e.g. 10 inches left and releases mouse button... The Window will then continue to move around the screen for 2-5 seconds more!
Speculation #1
I think the message queue may be flooded with paint-message related stuff meaning the move-messages get delayed? (which then again causes paints) Maybe some postmessage/sendmessage queuing going wrong.
What I have tried
I created some code that went through all controls in my form and disabled all events I could think of + called .Hide on them all -- this has no effect on the problem... However, I then created some code that went through all controls and removed them entirely -- this solves the problem if I remove say 50-80% of the controls.
Speculation #2
Is Windows draw style theming also done on controls not visible? (e.g. if placed on a TTabSheet not currently active?)
Other notes
In all honesty my form is very large (I spit out 7 different tools which all use most of it)
It is possible a TFrame based solution - as long as not loaded into memory - could solve this. But there are many problem in this... For one I have not abstracted reading e.g. options... I.e. I read myCheckbox.Checked to determine if a given option is enabled before passing it on my separated business logic.
But it is possible if I had a layer inbetween I could load TFrames as necessary... But it will be major work to convert to this.
...
Any ideas on how to workaround this? Reducing the problem is enough... I am thinking about:
a) Removing what I can.
b) Replacing what I can with stuff not style theme drawn. (E.g. "debug" controls I use myself to understand what is going on)
c) Maybe loading some stuff in TFrame instead
d) Trying to figure out why invisible controls cause problems for the style theme drawing... Could I have them ignored somehow?
e) Disable themning while drawing?
f) Disable having window drawn while dragged even if Windows is configured to draw Windows while they are being dragged.
g) WM_WINDOWPOSCHANGING / WM_WINDOWPOSCHANGED and disable align + draw while it happens.
I am using Delphi XE3.
When I create a new VCL project and drop a TToolbar on it, everything works fine - except when I activate Form1.DoubleBuffered.
From that moment on, drawing of the toolbar is broken - in designtime, it's either black, transparent, or parts of the IDE (statusbar, toolbar, etc.) are copied into it. It changes between these options when I click on it and when I change to source code (F12) and back.
In runtime, it's always black.
With DrawingStyle=dsGradient, everything works as expected. Switching back to dsNormal breaks it again.
Deactivating Form1.DoubleBuffered repairs it.
Any hints how to work around that issue?
In my opinion the solution is to set TForm.DoubleBuffered to False. Using a value of True causes all sorts of other problems. This property worked reasonably well before XP themes, but since their arrival, using TForm.DoubleBuffered has not been viable, in my view.
In addition to the problems you have encountered, I've come across lots of painting flaws when using the Windows Basic theme. I know that's not mainstream, but I happen to see that a lot with remote access. And there's more. When you double buffer a form you stop the theme animation from working. For example, a default button pulses to indicate that it is the default button.
If you get resize flickering without double buffering the form, use the ideas from my answer to another question. From the comments it seems that the flickering you wish to combat is in a paint box. I obviously don't know the details, but my experience and instincts say that you should be able to deal quite easily with that flickering at a local level. There surely should be no need for the global form wide double buffering.
As reported in this article, When not to use DoubleBuffered, some controls like TToolBar and TRichEdit don't work well with the DoubleBuffered property set to true.
The reason be be found in documentation, TWinControl.DoubleBuffered, where some WinControls can't draw themselves on a temporary bitmap (as happens when DoubleBuffered is true).
One workaround can be to put the TToolBar on a TPanel.
I just discovered Fabric.js and though the documentation is a lacking a bit, it seems like it will handle everything I need for an HTML-based Dream Board tool I'm building. It appears that it doesn't play well with JQueryUI, though.
When I set any of my objects to be JQueryUI widgets, button, dialog box, etc...the control handles seem to be non responsive on the top half of my canvas items, and even on the bottom, the hit areas for resizing/rotating are greatly reduced, which makes the items hard to manipulate. Has anyone run into this? Is this a known issue? I checked github and have tried to search SO to no avail.
Thank you!
http://seismicdevelopment.com/test/no-jquery-uis.html - No JQuery UI Widgets...behaves how I'd expect.
http://seismicdevelopment.com/test/with-jquery-uis.html - Click 'Add Image', you'll get an image, but compared to the other page, you'll notice that the corners of the image aren't as interactive...you can move the image ok, but rotating and scaling is ver hit-or-miss.
The problem must be in offsets. jQueryUI is probably modifying height of those buttons, which moves canvas slightly down, comparing to how it was during initialization.
I explained this — and why it happens in Fabric — in more detail here.
I am using the new BrowserField2 in BlackBerry OS5 to display HTML content in my app. There are 3 options available for navigation through links in that content.
CURSOR navigation uses a block cursor and actually moves through the characters of the page. Not very useful for me.
POINTER navigation uses a mouse like pointer that you move around the screen and hover over elements. This could work but there is a bug however in that the browser field captures navigation and never lets go so this mode is effectively broken if you share a screen with any other managers. Once your focus enters the browser field you cannot move focus back out and into neighboring fields. RIM has acknowledged the bug but has no work around.
NONE which is for custom navigation but they offer no explanation as to how you would do this.
What I ideally want is to simply have trackpad movements move the focus through the links and highlight them. Then a click would activate the link. I assume I would select the NONE option above and implement my own focus navigation but I am not clear how this can be accomplished with the new APIs.
Is anyone familiar with the new browser2 component could give some guidance?
Thanks!
There's a workaroudn to getting back the focus out of the BrowserField using the NAVIGATION_POINTER.
I found it in this thread:
http://supportforums.blackberry.com/t5/Java-Development/BrowserField-2-Navigation-Mode/td-p/632172
"farahh" posted this:
I found out a hack..
with the navigation set to pointer mode, a click outside the browserfield manager invokes Manager.invokeAction(int). I used the getFieldWithFocus to verify which field has focus and then switch the focus to something else.
Cheers.
Nahuel
PD: i havent found out how to get the behaviour you want, i need that as well so if you got it working please let me know, its kinda urgent in my project =(
I actually reverted back to the older browser1 (OS4) component because the navigation problems in browserField2 (OS5) were a deal breaker for me. Luckily the OS4 browser does everything I need in terms of functionality and it has the exact navigation behavior I need and there are no focus problems mixing it with other views.
Windows in my application are popping up off the edge of the screen, and this of course is a problem because some of the windows are modal and can't be dismissed (you don't even know they are there).
I'm using the TurboPower Orpheus component which remembers the location and size of each form, then restores it when the form is shown again. It saves the size and placement in an INI file.
What can I do to prevent windows from ever showing off the side of the screen?
It's common for this sort of thing to happen if you use multiple monitors and then disconnect one, such as when undocking a laptop. Or if you dock a laptop to a screen with a higher resolution. Or use remote desktop, etc..
The remedy is to override the "remember my position" behavior with a sanity check, to see if the left+width exceeds the width of the screen (Screen.Monitors array, actually - thanks guys), and vice-versa for the top+height.
Ideally, you "bump" by subtracting the difference, so you're butting up against the edge that the window wanted to straddle.
Also, see if there are updates to Orpheus that fix this. If not, you can get the source, make the correction (optional), and contribute it back to the project. It's OSS, as I recall.
You may want to give a look at their DefaultMonitor property and read the code from TCustomForm.SetWindowToMonitor to see how to deal with positioning relatively to Screen.Monitors.
Use DefaultMonitor to associate a form with a particular monitor in a multi-monitor application. The following table lists the possible values:
Value Meaning
dmDesktop No attempt is made to position the form on a specific monitor.
dmPrimary The form is positioned on the first monitor listed in the global screen object's Monitors property.
dmMainForm The form appears on the same monitor as the application's main form.
dmActiveForm The form appears on the same monitor as the currently active form.
Note: DefaultMonitor has no effect if the application does not have a main form.
To recall the previous position of a form, without having it suddenly in an area which is no longer available (due to a plugged off screen or changed resolution), you just call
TForm.MakeFullyVisible;
That's it. See the documentation.