I've been struggling with this problem for far to long now, and I'm guessing the solution is quite easy.
In my Flex application, I've got a component that extends UIComponent where I'm loading images at runtime and try to display them. I've tried lots of different approaches (using beginBitmapFill(), using different containers), but I can't get things to work as I want. The problem seems to be related to the width and height properties of the image, which aren't updated correctly.
The idea is:
var sprite:Sprite = new Sprite();
addChild(sprite);
var im:Image = new Image();
im.addEventListener(Event.COMPLETE, function(e:Event):void {
sprite.addChild(im);
}
im.load('path/image.png');
The image's width and height doesn't seem to be correct when it's loaded. I get width==0 (and nothing is displayed), but the property $width seems to be correct. How can I assure that width and height of the loaded image is updated?
This is a timing problem, and imho a bug in the image class, because the image class breaks the expectations of the users.
The thing is, the image class first does the downloading (and eventually dispatches COMPLETE), and then does the measuring (and scaling) and then updates the values correctly (resulting most of the time in another UPDATE event).
So when I first stumbled upon this problem, my solution was to first listen to the COMPLETE event, then add a listener to UPDATE (you can't just listen to update because this usually will be dispatched at least once during creation or download), but this is rather a bad hack.
I'm quite sure this question has been answered before on stackoverflow, and there probably were better solutions.
PS: also beware of the difference between width and contentWidth, just to be sure :)
try it with Event.INIT instead of Event.COMPLETE
Related
i am currently trying to integrate a responsive map on my website, which i built with WIX code.
I am basically starting off with the code provided by Here maps to create an interactive map (https://developer.here.com/api-explorer/maps-js/v3.0/maps/map-at-specified-location).
I integrated the code into the html iframe and it works without any problems. But as soon as i want to define the height (for responsive matters), the map vanishes and will only return if i type in the div height in px.
I am not that much of a talent when it comes to coding but i am trying really hard to get this stuff done.
Best regards,
Daud
If you want the map to resize accordingly to container or window resize, make sure to have a handler for this:
// Window resize handler
window.addEventListener('resize', function () {
map.getViewPort().resize();
});
Note: The variable map refers to your initialized HERE map object, normally to be found where the line new H.Map(...) is called.
UPDATE:
I just found a piece of sytle.css within Here Maps that helped me out with the responive div. It seems as long as there is a certain px number added to the div, the content may only be partial responsive. Obviously somehow but still complicated...
Thanks for your interest and help, guys!
[qt 4.8]
To get correct window dimensions including its frame, I do the following (as described e.g. here, see comment from Daniel Hedberg).
mainWindow.move(-50000, -50000);
mainWindow.show();
// do something with the window dimensions
mainWindow.move(0, 0);
mainWindow.show()
This works fine, however, I have a problem with the move(0,0) call: It makes the window always appear at position (0,0), while I would like to have the default behaviour, this is, the application only suggests to the window manager that (0,0) is a good place to position the window, and the WM might decide to shift it if necessary to avoid overlapping. In other words, I would like to switch back to Qt's default behaviour as if there weren't a call to move at all.
How can I do that?
One solution is to store Windows original position and use that. For extra safety (in case screen resolution changes), check that entire window still fits on screen and move and even resize if it does not.
A hacky alternative would be to create and open empty, possibly transparent dummy window of the same size and see where it gets positioned. Then move the original there and close the dummy one. Reading your question carefully, I think this would do what you are after.
I don't know of a Qt way to ask Window Manager to reposition the window, so if you really need that, specify the OS etc details.
Looking into the source code of Qt, I can now partially answer my own question: To convert a call to move into a suggestion for positioning instead of a request, do this:
mainWindow.move(100, 100);
mainWindow.setAttribute(Qt::WA_Moved, false);
mainWindow.show();
I've tested the code under X11 using Qt 4.8.4, and hopefully it works with on other platforms too.
Unfortunately, this doesn't solve the very problem I have, namely to use show to get the (decorated) dimensions of an off-screen window which then gets moved to the screen, calling show again. It seems that the first call to show directly sets platform-specific window manager flags which aren't completely reset and reevaluated in the second call. Actually, I'm going to think that this is a bug in Qt, so I'll report it accordingly.
Having recently switched to autolayout in Xcode 5 (and having watched the developer video from WWDC 13), I'm finding things to work pretty well with the exception of a View-Based NSOutlineView.
Before autolayout, this worked. Everything works fine and is in the right location, but now, specifically when I scroll, some of the new entries (and not all of them) end up in the wrong place, always larger and slightly higher.
The problem goes away once they are redrawn, but I don't understand the mechanic for drawing these NSTableCellViews and when they are created by the Outline View. I mean, it looks like they are created at some point, the program is guessing about the proper constraints, and then fixing them after a redraw.
It would be really nice to post an image to explain this, but can someone explain the life cycle of a view in an NSTableView or NSOutlineView?
I had to grapple with that issue myself and I was able to fix it today. This will happen if you are using any content inside an NSTableCellView that needs to be resized to fit into its cell or any subview of it. I fixed this problem by using an NSImage with the exact same size as a placeholder NSImage I added as subview to the NSTableCellView on IB. This resizing will break the constraints you added to or expect in this view.
I am having problems finding the width of a string of text in a UITextField object. I know there are various methods documented to ostensibly do this, but they simply do not work. There is one and only one method that produces a correct value, but requires the use of the textField property of an mx.controls.Text object. If that textField is used, then getCharBoundaries works correctly, and you can just add up the returned widths from a series of calls to it to get the width of a string of text.
However, if you just call getCharBoundaries on a stand-alone TextField or UITextField (i.e. one that is not a property of MX:Text) then getCharBoundaries returns some entirely different value that is substantially less than if called on the textField property of an Mx:Text object. It is in fact about 25% smaller than the correct value, but that is not even consistent, because change the font size and the discrepancy seems to vary non-linearly. So what getCharBoundaries is actually returning in the case of a stand-alone UITextField, I have no idea.
But actually, call any other method for determining text width of a TextField (other than getCharBoundaries within an MX:Text object) , and you'll get the same erroneous value: TextField.getUITextFormat().measureHTMLText(...).width (or measureText), and TextField.getLineMetrics(...).width all return this same erroneous value. And you might say, "Well they're probably just returning the width from left most pixel in the text to righmost pixel", except as I said to begin with, in one instance getCharBoundaries is actually returning the total cell width of the text, which is what I want, (and then when called from a stand-alone Textfield some completely different value.)
But my problem first appeared when I tried to change an MX:Text object (within which I could call getCharBoundaries successfully) to a UITextField. So now neither getCharBoundaries or anything else works correctly for determining text width. (Note: I'm not actually displaying the UITextfield, but rather am using it for text processing purposes behind the scenes, as it is significantly faster than MX:Text. I set UITextField.htmlText to a value, then make a series of calls to getTextFormat, setTextFormat, and replaceText. And it all works as before with the Mx:Text object, except much faster. Only problem is there is now apparently no way to determine text width for a string of text, even though Adobe documents all these methods that are supposed to do that.
And so my question is, I get on google, and there is very little commentary on this, and no work around at all that I have seen documented anywhere. I did see one thread on actionscript.org from a couple of years ago, where someone else also said that all these width methods simply do not work. There was confirmation of this by someone, but no resolution provided. (Note: this poster noted that the error seemed to escalate with increasing font sizes and was not as noticeable at small font sizes, which I suppose may explain why it doesn't seemed to have been noticed.)
But I downloaded Flex 4 here a while ago, and the problem is still there. So just wondering if I am truly the only person who is cognizant of this, or has encountered it, or possibly someone point out what I'm missing. I guess the Flex Bug tracking system would be an option for me, but that would probably be a Black Hole.
So anyway, just wondering if anyone's encountered this or found a work around.
OK, I've solved my problem. I apologize for the rant against Adobe but then again I might not have solved this otherwise.
The problem was rather obscure and almost certainly not relevant to others, but here it is:
I was trying to find the text width of a prefix that contains some characters in a special nonstandard utility font I created with very nonstandard attributes. Mx:Text.textfield.getCharBoundaries had no problem with it, but every other width method did, evidently. Of course, Mx.Text.textField is not actually a TextField or a UITextField, but rather an IUITextField, meaning it just implements the interface. Evidently its implementation may have nothing in common with the implementation of TextField and UITextField which are both directly related.
As far as this nonstandard font, I had not had any problem with it in the past, so failed to identify it as the culprit. Its character widths are identical to another font's, so that solves my problem.
I have to provide an update here. The problem wasn't the font I was using, but rather that it was not a Windows System Font. measureText, measureHTMLText, etc. won't work unless a font is installed on a user's own system previously. It makes no difference if the font is embedded in the Flex Application, the end user has to already have that font installed on his own system for those width methods to work. MX:Text.textField.getCharBoundaries is the only one that doesn't care whether or not its a systemFont. (UITextField.getCharBoundaries also requires it to be a system font.)
I have a simple Flex application that is a panel with a repeater inside of it; albeit a little simplified, it is like such:
<mx:Panel id="pnl">
<mx:Repeater id="rp">
<mx:Label text = "foo" />
</mx:Repeater>
</mx:Panel>
I am then embedding this Flex application into an HTML wrapper. I am then attempting to dynamically re size the embedded Flash object in the HTML as the Flex panel changes size (thus allowing the Flex application to consume as much of the HTML page as it needs).
I am doing this by doing the following actionscipt:
pnl.addEventListener(ResizeEvent.RESIZE,function(event:Event):void {
ExternalInterface.call("resize",event.target.height);
});
which in turn calls this javascript function:
function resize(height) {
// the embed or object that contains the flex app
var e = document.getElementById('flex_object');
if(e) e.height = height;
}
This seems to work perfect in IE, however I get strange results in Firefox / Safari, the repeater works for n number of times, and then the text seems to get cut off / disappear in the repeater, see the attached image:
alt text http://img528.imageshack.us/img528/9538/rpre0.jpg
Can anyone explain why this is happening, and if there are any workarounds / ways of doing the same thing?
I'm currently working in the same thing (a swf that dynamically changes it's height depending on the content it's currently holding). I also had a similar problem to yours trying to make a multi-line button.
I'm new to flex but I managed to solve the problem manually invoking the updateDisplayList() of the container... I think it "forces" a render somewhere... it's parameters are the width and height of some area where the changes happen. Sorry for not knowing the details... But it worked for me.
Why not simply using percent width and height on your HTML page for your Flash object ? This way you event don't have to do anything to resize your SWF...
That's very strange - it looks like Firefox/Safari are expanding the draw area of the embed, but somehow Flash is not getting the message that it needs to render the new pixels.
You could probably work around this by doing something to force Flash to update itself, but since the communication between the browsers and the embed seems to be confused it would probably be less hackish to take a different approach, that fits into the browsers' event flow without bugging.
For example, instead of resizing the embed, you might try putting Flash inside a DIV, setting the Flash's size to 100%, and then resizing the DIV. That seems a lot less likely to misbehave.
My experience is that Flex's resizing abilities are... funny. Sometimes they work the way one would expect, other times they do not. There are a couple of things you could try: first, trace the value you expect to get in Flex for the height or even ExternalInterface.call("alert",event.target.height); This will let you know if it is a JavaScript or a Flex problem for sure (but I suspect it is Flex).
Your problem might have to do with the scaling of the component:
Setting [the height] property causes a resize event to be dispatched. See the resize event for details on when this event is dispatched. If the component's scaleY property is not 100, the height of the component from its internal coordinates will not match. Thus a 100 pixel high component with a scaleY of 200 will take 100 pixels in the parent, but will internally think it is 50 pixels high.
If it is Flex and that does not help, I would try using callLater in front of the ExternalInterface call, often that will allow Flex enough time to figure out what the heck it is doing. Occasionally, setTimeout is needed, but I find that awkward.