I'm working on a project where there is an Image (spark or mx) and when I set the visibility to false it still remains! It seems to dim instead of remove. I'm thinking that maybe something, a sprite or display object somewhere or some graphics command is somehow capturing a screen grab while the image is visible and leaving a phantom image. I can't track it down. Has anyone heard of this?
I'm using Tweener and I think it may have something to do with it but again it's a large project and this problem is nested deep within it.
UPDATE
I think it has to do with Tweener. I removed the tweens and visibility started to work as described. I think it may have been that Flex defers committing the value of a property and it's effect until the render event. So it maybe set to false but it may not actually be invisible until the next validation / render phase while Tweener does it's thing right away.
I commented out the Tweener and other code related to it for now and I'm not going to put more resources into it tracking it at this time.
Do you have it in a container? I have not had a problem setting visible=false and it still being displayed. As jidma said, try includeInLayout, another thing to try is setting the parent visible=false
Related
I'm setting up a UIRefreshControl in my uitableviewcontroller, but there is a big gap between the navbar and the top of the uitableview. Playing with 'adjust scroll view insets' doesn't help, as the controller will underlay the navbar at startup. I could disable 'under top bars', but I want that ability when scrolling. When poking around in the debugger, I noticed at various times the tableView.contentInset is offset by 82 points, which is different from the ususal 20/64 pt offset people talk about regarding the new ios7 bar behavior. What's going on here?
Found a solution while poking around more; hope it saves someone a few hours!
I needed to instantiate my UIRefreshControl after viewDidLoad:, or avoid setting its attributedTitle in code at least until after that (e.g. if I enabled refreshing of the table in IB). Setting the string inside viewDidLoad: messes up iOS's layout of the control+tableview, but it's ok within viewWillAppear: or later once the geometry is set. And I think 82 points is the height of the UIRefreshControl. Setting the refresh title in IB would've also avoided this problem, except that I was doing so in code because I didn't want to have to enable refreshing in IB all the time with each of my tables.
So updateDisplayList is for laying out, positioning and sizing a component's children. It seems a waste to me, however, to have all that code running every time a render is called, even if no changes have been made to the relevant properties or child properties.
The way I get around this for performance's sake (working on mobile) is to set a flag inside of my overridden updateDisplayList that lets a big part of my own sizing/positioning code run only the first time.
Is this a bad idea/ big mistake? I just can't see the benefit to letting it run every time otherwise if I don't expect anything that affects sizing/positioning to change.
It seems a waste to me, however, to have all that code running every
time a render is called, even if no changes have been made to the
relevant properties or child properties.
I agree completely.
The way I get around this for performance's sake (working on mobile)
is to set a flag inside of my overridden updateDisplayList that lets a
big part of my own sizing/positioning code run only the first time.
What I've done--and is very common in the Flex Framework--is to have a property for every main item that needs to change. For example, our MX AutoCompleteComboBox has a property named "downArrowVisible" and if you set it to false it will hide the down arrow from display, while also resizing the textInput to spread across the full width of the component. If you set it to true; it will position items like the normal ComboBox.
So, whenever the property downArrowVisible is changed, we set a flag there, downArrowVisibleChanged; and use that property to determine whether updateDisplayList should change position of the elements. [It's slightly more complicated than that, but that is the gist]. The default of downArrowVisibleChanged is true so that during the initial setup run the children components will be sized and positioned correctly.
This sounds very similar to what you're doing; as I never have a flag property specific to updateDisplayList(). I make my flags specific to a certain piece of the layout, and only set those flags to 'no longer need to be changed' in updateDisplayList().
Is this a bad idea/ big mistake? I just can't see the benefit to
letting it run every time otherwise if I don't expect anything that
affects sizing/positioning to change.
I think it seems like a logical approach. You are correct, there is no need to having your layout code consistently running every time the component redraws.
If you will not be changing properties of your custom component at runtime and only want your updateDisplayList() routine to run once--and never again--then I think you can tie into the initialized property of the Flex Framework without adding your own Boolean value. IF the value is false, then the component hasn't been through it's initial creation process yet. If the value is true then it has.
I'm using http://code.google.com/p/flex-iframe/ for showing html in an flex application. To set this up I need to set vmode=opaque. But doing this messes with keyboardinput (at least a swedish charlayout) in Firefox. For example a press on the array key resolves in two arrow chars/steps. If I remove vmode=opaque it works again.
There have historically been lots of issues with setting wmode to opaque. I've had similar issues in the past and had to resort to removing this wmode setting. However, if you're so inclined you could hackishly detect the presence of two keyboard input events within a relatively short time period and suppress one of them. It's not a really elegant solution but if you cannot get rid of wmode, it might be a viable workaround until the bug is fixed by adobe.
Facebook Connect uses JS/CSS overlays/popups for user interaction. I have sites with Flash elements, and no matter how I set the z-indices, the Flash always seems to go to the top.
I have a similar and likely related problem with a div with display:fixed at the top of the screen, where it gets covered by the Flash when you start scrolling.
How can I make sure the Flash element layers properly?
If you just need your flash to fall behind other object then you should use wmode=opaque. This will correct the z-index.
wmode=transparent will also correct the z-index but it also makes your stage transparent so whenever you have nothing on the stage or gaps between objects your html will show through underneath. This in turn causes more system strain.
Ergo if you just need the z-index correcting use wmode=opaque
Generally, I've needed to set the wmode=transparent property on the Flash object and/or embed string.
http://www.communitymx.com/content/article.cfm?cid=e5141
Sort of a complicated scenario - just curious if anyone else could come up with something:
I have a Text control and when I scroll it and stop the scroll with the cursor over some text that has a url, the cursor doesn't revert to a hand, and also flash player starts acting as if a selection is being made from the last cursor position. So IOW a bonafide bug in flash as far as I can determine.
The above probably wasn't completely clear so let me elaborate. If you grab a scrollbar thumb and start moving it up and down, you don't actually have to keep the mouse pointer on the thumb while doing so. When you stop the scroll, the mouse pointer could be outside the browser window, inside your flash application, but not currently on the scroll bar thumb, or wherever. The previously mentioned bug occurs when you stop the scroll with the mouse pointer positioned over text with an html anchor (a hyperlink). At that point the cursor enters into some state of limbo, and doesn't show the url hand pointer, and furthermore acts as if some text selection is taking place from the last cursor position prior to the scroll.
So the question would be, what sort of event could I simulate in code to jolt flash out of this erroneous state it is in. And furthermore in what event could I perform this simulated event (given that for example there is no AS3 event to signal the end of a scroll.)
To be clear, the Text control in question is on a canvas, and that canvas (call it A) is on another canvas which actually owns the scrollbar, and scrolling takes place by changing the scrollRect of canvas A.
I have run into this exact same problem with the TextArea in Flex 4: Scroll (textarea content is large than it's container) and release the mouse when over a link, and the cursor doesn't act right.
I think it's a bug, try submitting it to the Adobe Bug and Issue Management System. I will vote for it :).
Are you using Flex 3 or 4? If you're in Flex 4, I can make some suggestions. As a base, I would examine the TextArea and related source code in the Flex 3 SDK and figure out what events are being dispatched from links and whatnot. If you can eliminate the possibility that it's a Flash TextField (which TextArea uses), then it's a Flex bug. Try dispatching events that they're dispatching within the TextArea, from the things that are dispatching it (Event.CHANGE is all I can see taking a quick glance).
Good luck!
This is really in response to viatropos.
I was just able to duplicate the bug using the code example from the end of the Text documentation page in Flex 3.5 reference.
Just replace their htmlText in that example with a huge block of htmlText containing anchors tags (<a>...</a>). Then make the browser window small. Then click some arbitrary area of the htmlText with the mouse (That step is important.) Then scroll using the thumb. Stop the scroll with the cursor directly over one of the hyperlinks you created and release the mouse. The entire block of htmlText is selected and highlighted and the mouse pointer will not revert to a hand. (Well it will after you click somewhere else.)
As far as reporting this to adobe through their bug tracking system, I guess if I want to wait several months for it to be fixed. I reported another genuine bug over a year ago that was never fixed.
But examining their source code as you suggested - probably my best bet.