Change visible property sometimes change the center position of the view (possible bug?) - position

I've 3 (loader, locker and debug view) hidden views (touchEnabled and visible set to false, and zIndex to 1) above the main view (zIndex = 2).
Each 'over' view has this method:
$.debugView.show = function() {
$.debugView.touchEnabled = $.debugView.visible = true;
$.debugView.zIndex = 3;
};
$.debugView.hide = function() {
$.debugView.touchEnabled = $.debugView.visible = false;
$.debugView.zIndex = 1;
};
This screen has the 3 'over' views hidden:
Now, I'm opening the 'debug view', but, SOMETIMES it seems like it changes the positions (as if the center it's on the top left corner instead of the center of the device).
Instead of the required result:
If I use the opacity instead of the visible property, it works properly.
This might be an SDK bug right?
<Alloy>
<Window>
<View id="content"/>
<View id="locker"/>
<View id="loader"/>
<View id="debugView"/>
</Window>
</Alloy>
All of these 4 views don't have width or height (so it uses the Ti.UI.FILL as default)

I have noticed this too with a completely different implementation. I had just one view that I included in a window.
Apparently the left and top calculations were not done properly if the elements is hidden.
What I did to solve the issue is to hardcode the left/top position by calculating the left position using this:
$.content.left = (Ti.Platform.displayCaps.platformWidth - 75) / 2;
Where in my case 75 is the width the element has, so that'll be bigger in your case. You can do the same for height.
Now, this is an iOS only solution. On Android you will need to take DPI into consideration calculating it.
I do think it is a bug, though this solution works perfectly for me. I recommend looking at JIRA and see if it is a known issue, and if not, raise it with a very specific explanation of the problem, preferably with a reproducible case delivered as an app. Classic would help most. And if it is not reproducible in classic it might be an alloy issue.

Related

Using CMFCMenuButton::SizeToContent does not seem to work as I would like. Why?

I am perplexed about the SizeToContent method of the CMFCMenuButton control.
This is my dialog in the IDE:
As you can see, I have specifically made the button wider than the two on the far right.
I added the following code to OnInitDialog:
// Resize (if required)
const auto sizNewButton = m_btnReset.SizeToContent(true);
CRect rctButton;
m_btnReset.GetWindowRect(&rctButton);
if(sizNewButton.cx > rctButton.Width())
{
m_btnReset.SizeToContent();
}
Yet, when I run my application in English:
It has made it smaller. My application supports 50+ languages by using satellite DLLs and I was hoping to only resize to content if it was required. But it seems to resize it anyway. Have I missed a step here?
I have checked the properties for the control in the IDE and it is not set to auto resize:
I notice that the help documentation states:
The new size of the button is calculated to fit the button text, image, and arrow. The framework also adds in predefined margins of 10 pixels for the horizontal edge and 5 pixels for the vertical edge.
I had a look at my button:
Default size: 48 x 23 (the GeWindowRect result).
Calculated size: 57 x 23 (the SizeToContent result).
If I adjusted my code like this:
if((sizNewButton.cx - 10) > rctButton.Width())
That would bring it down to 47 and thus would not resize. I am assuming the code is not working right because of the padded margin that GetWindowRect knows nothing about.
Searched it, and found that the problem is MFC's CMFCMenuButton::SizeToContent() implementation in afxmenubutton.cpp:
CSize CMFCMenuButton::SizeToContent(BOOL bCalcOnly)
{
CSize size = CMFCButton::SizeToContent(FALSE); // <==== The culprit!!!
size.cx += CMenuImages::Size().cx;
if (!bCalcOnly)
{
SetWindowPos(NULL, -1, -1, size.cx, size.cy, SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER);
}
return size;
}
That is, it calls the base implementation of SizeToContent() with the bCalcOnly parameter set to FALSE, which means it will also resize the control to just fit the text (without the drop-down arrow). This is less than required for the text plus the arrow, and of course the original size is lost.
A workaround can be get the (original) width, before the SizeToContent() call, and work with this instead of the new one:
CRect rctButton;
m_btnReset.GetWindowRect(&rctButton);
const auto nOrigWidth = rctButton.Width(); // Store the original width
const auto sizNewButton = m_btnReset.SizeToContent(true); // This resizes the control!!!
if (sizNewButton.cx > nOrigWidth) // Compare to the original width rather than the new one
m_btnReset.SizeToContent();
else // Restore original width
m_btnReset.SetWindowPos(NULL, -1, -1, nOrigWidth, sizNewButton.cy, SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER);
Alternative Workaround:
Define a new CMFCMenuButton-based class, overriding SizeToContent() - in the implementation call the base CMFCButton::SizeToContent() with the bCalcOnly parameter passed by the caller, not with FALSE. Map the control to this class instead of CMFCMenuButton. That is use a class that fixes it. Too much of an overkill for just a workaround though.

Any way to get a HaxeFlixel group to clear out?

There is a too long, didn't read version down below.
So I've been making a little game in which the player has to click on a grid of bricks that matches the color of the needed brick in the upper right hand corner of the screen. After they click on the needed color, the bricks explode and the bricks of the same color next to them explode as well creating combos. That leaves holes in the grid so I have to somehow reset the grid itself without resetting the gamestate itself. I've got something working right now which is this:
private function ResetNow():Void
{
if (Restter == 1) Restter = 0;
//if this block is up here, same results
/*
wantedBricks.kill();
wantedBrik._changeColor = FlxMath.rand(0, 2);
bricks.autoReviveMembers = true;
bricks.revive();
*/
Restter = 0;
//Removes stray detectors so the neverending combo bug won't occur
for (stray in dets.members) stray.kill();
if (Restter == 0)
{
wantedBricks.kill();
wantedBrik._changeColor = FlxMath.rand(0, 2);
bricks.autoReviveMembers = true;
bricks.revive();
wantedBricks.autoReviveMembers = true;
wantedBricks.revive();
for (zgem in bricks.members) zgem.EQUITYCHECK = FlxMath.rand(0, 2);
}
//add(bricks);
Restter = 1;
}
So, again, I have a grid of blocks set up at create, that is group bricks. And I have a sprite in the upper right corner which is wantedBrik. What happens during gameplay, is the player clicks on the bricks that matches the wanted bricks to clear them out of the grid. When there are no more wantedBricks(a group), it is supposed to reset the grid, and change the color of the wantedBrik. I also have it somewhere else in the code that if a member of the big grid's EQUITYCHECK(basic object hacked in value) is equal to the wantedBrik, add it to the wantedBricks(which, is why I'm checking for no more of them). So, what happens?
Well, if the color of the wantedBrik doesn't change, everything's fine and resets like normal. the wantedBricks group acurately counts the bricks that actually match the wantedBrik's color. And when it does change, for some reason, gameplay is normal. BUT, wantedBricks not only thinks that the old color is still needed, but it also thinks the new color is still needed too. So when the player clicks the new needed color bricks, they do explode, but because wantedBrik thinks the old color is still wanted, it doesn't hit null and the grid won't reset.
What can I do to make sure that wantedBricks behaves correctly after a color change?
TL;DR version: I need to get a Haxe array to forget or lose old numbers. How can I do this?
The "Pirate Pig" sample may be useful to you. Since it is a puzzle game, there may be some similar problems that were solved there. You can find it using openfl create or nme create depending on which you are currently using.
You can create a simple array like this:
var myArray = [];
You can also type arrays, like this:
var numbers = new Array<Float>();
Then you can use push(), concat() and other array methods.

How do I dock a UserControl into a FlowLayoutPanel?

I have a FlowLayoutPanel and a UserControl.
I've added multiple usercontrols into the FlowLayoutPanel, and I'm trying to dock them to the top, so when I change the size of the FlowLayoutPanel the size (width) of the usercontrols changes accordingly.
You cannot dock anything inside a FlowLayoutPanel, it's simply ignored.
Check out the answer here apparently posted by the Microsoft team.
They say:
The FlowLayoutPanel relies on a largest control to effectively define the column/row within it. The code below set's the size of the first control to the width of the FLP to achieve a layout similar to what you want.
private void flowLayoutPanel1_Layout(object sender, LayoutEventArgs e)
{
flowLayoutPanel1.Controls[0].Dock = DockStyle.None;
for (int i = 1; i < flowLayoutPanel1.Controls.Count; i++)
{
flowLayoutPanel1.Controls[i].Dock = DockStyle.Top;
}
flowLayoutPanel1.Controls[0].Width = flowLayoutPanel1.DisplayRectangle.Width - flowLayoutPanel1.Controls[0].Margin.Horizontal;
}
Key thing is to use the Layout event.
This solution worked for me up to a point. Your UserControls have to have AutoSize turned off / stay a uniform size.
In my case I wanted AutoSize turned on so as to allow the UserControl to expand/contract vertically while filling the width of the FlowLayoutPanel.
I had to find a different solution. But the above might help you in your case.

tag cloud, layout: horizontal, and Appcelerator Titanium

Please note: This question relates to the Appcelerator Titanium platform, not the stock iOS SDK.
I'm making a tag cloud with a layout: horizontal view. I'm most of the way there, but I can't get the final Titanium.UI.Label on a line to wrap if it doesn't fit. Instead, it gets ellipsized (in a useless manner).
Is there a way I can prevent this on iOS? Seems to work fine on Android.
If you try to set the label width to auto, Titanium will calculate the label width in runtime.
It make sense to get a ellipsized label in horizontal view.
You may need to determine the dynamic label width in your tag cloud case. But just leave it to titanium, you just need to change the dynamic width to static width with this tricky code.
for (var i = 0; i < data.length; i++) {
var label = Ti.UI.createLabel({ text: data[i], width: 'auto', height: 20,left: 5, top: 5});
label.width = label.width + 5; //this determine width in runtime assign back to static width
view.add(label);
}
The iPhone's answer to this is minimumFontSize but that makes no sense in a tag cloud... Have you considered adding this to a horizontal scrollview and setting the contentWidth to auto?
Also does each of your label have it's width set to 'auto'? I imagine setting that would cause the word to overflow the layout and be pushed down to the next line.

SVG Word Wrap - Show stopper?

For fun I am trying to see how far I can get at implementing an SVG browser client for a RIA I'm messing around with in my spare time.
But have hit what appears to be a HUGE stumbling block. There is no word wrap!!
Does anyone know of any work around (I'm thinking some kind of JavaScript or special tag I don't know)?
If not I'm either going to have to go the xhtml route and start sticking HTML elements in my SVG (ouch), or just come back again in ten years when SVG 1.2 is ready.
This SVG stuff is baffling, isn't it ?
Thankfully, you can achieve some good results, but it takes more work than using the HTML 5 .
Here's a screenshot of my ASP.Net / SVG app, featuring a bit of "faked" word wrapping.
The following function will create an SVG text element for you, broken into tspan pieces, where each line is no longer than 20 characters in length.
<text x="600" y="400" font-size="12" fill="#FFFFFF" text-anchor="middle">
<tspan x="600" y="400">Here a realy long </tspan>
<tspan x="600" y="416">title which needs </tspan>
<tspan x="600" y="432">wrapping </tspan>
</text>
It's not perfect, but it's simple, fast, and the users will never know the difference.
My createSVGtext() JavaScript function takes three parameters: an x-position, y-position and the text to be displayed. The font, maximum-chars-per-line and text color are all hardcoded in my function, but this can be easily changed.
To display the right-hand label shown in the screenshot above, you would call the function using:
var svgText = createSVGtext("Here a realy long title which needs wrapping", 600, 400);
$('svg').append(svgText);
And here's the JavaScript function:
function createSVGtext(caption, x, y) {
// This function attempts to create a new svg "text" element, chopping
// it up into "tspan" pieces, if the caption is too long
//
var svgText = document.createElementNS('http://www.w3.org/2000/svg', 'text');
svgText.setAttributeNS(null, 'x', x);
svgText.setAttributeNS(null, 'y', y);
svgText.setAttributeNS(null, 'font-size', 12);
svgText.setAttributeNS(null, 'fill', '#FFFFFF'); // White text
svgText.setAttributeNS(null, 'text-anchor', 'middle'); // Center the text
// The following two variables should really be passed as parameters
var MAXIMUM_CHARS_PER_LINE = 20;
var LINE_HEIGHT = 16;
var words = caption.split(" ");
var line = "";
for (var n = 0; n < words.length; n++) {
var testLine = line + words[n] + " ";
if (testLine.length > MAXIMUM_CHARS_PER_LINE)
{
// Add a new <tspan> element
var svgTSpan = document.createElementNS('http://www.w3.org/2000/svg', 'tspan');
svgTSpan.setAttributeNS(null, 'x', x);
svgTSpan.setAttributeNS(null, 'y', y);
var tSpanTextNode = document.createTextNode(line);
svgTSpan.appendChild(tSpanTextNode);
svgText.appendChild(svgTSpan);
line = words[n] + " ";
y += LINE_HEIGHT;
}
else {
line = testLine;
}
}
var svgTSpan = document.createElementNS('http://www.w3.org/2000/svg', 'tspan');
svgTSpan.setAttributeNS(null, 'x', x);
svgTSpan.setAttributeNS(null, 'y', y);
var tSpanTextNode = document.createTextNode(line);
svgTSpan.appendChild(tSpanTextNode);
svgText.appendChild(svgTSpan);
return svgText;
}
The logic for word-wrapping is based on this HTML5 Canvas tutorial
I hope you find this useful !
Mike
http://www.MikesKnowledgeBase.com
UPDATE
One thing I forgot to mention.
That "Workflow diagram" screen that I've shown above was originally just written using an HTML 5 canvas. It worked beautifully, the icons could be dragged, popup menus could appear when you clicked on them, and even IE8 seemed happy with it.
But I found that if the diagram became "too big" (eg 4000 x 4000 pixels), then the would fail to initialise in all browsers, nothing would appear - but - as far as the JavaScript code was concerned, everything was working fine.
So, even with error-checking, my diagram was appearing blank, and I was unable to detect when this showstopper problem was occurring.
var canvasSupported = !!c.getContext;
if (!canvasSupported) {
// The user's browser doesn't support HTML 5 <Canvas> controls.
prompt("Workflow", "Your browser doesn't support drawing on HTML 5 canvases.");
return;
}
var context = c.getContext("2d");
if (context == null) {
// The user's browser doesn't support HTML 5 <Canvas> controls.
prompt("Workflow", "The canvas isn't drawable.");
return;
}
// With larger diagrams, the error-checking above failed to notice that
// the canvas wasn't being drawn.
So, this is why I've had to rewrite the JavaScript code to use SVG instead. It just seems to cope better with larger diagrams.
There is also foreignObject tag. Then you can embed HTML in SVG which gives the greatest flexibility. HTML is great for document layout and has been hacked to no end to support application layout, drawing, and everything us developers want. But it's strength is word wrapping and document layout. Let HTML do what it does best, and let SVG do what it does best.
http://www.w3.org/TR/SVG/extend.html
This works for most browsers FireFox, Opera, Webkit, except IE (as of IE11). :-( Story of the web ain't it?
SVGT 1.2 introduces the textArea element http://www.w3.org/TR/SVGTiny12/text.html#TextInAnArea , but it is only experimentally supported by Opera 10 at the moment. I don't know if other browsers will ever plan on implementing it, though I hope they will.
Per this document, it appears that tspan can give the illusion of word wrap:
The tspan tag is identical to the text tag but can be nested inside text tags and inside itself. Coupled with the 'dy' attribute this allows the illusion of word wrap in SVG 1.1. Note that 'dy' is relative to the last glyph (character) drawn.
The svg.js library has a svg.textflow.js plugin. It's not ultra fast but it does the trick. It even stores overflowing text in a data attribute so you can use it to create continuously flowing columns. Here the text flow example page.
An alternative method is to use Andreas Neuman's text box object.
These days, flowPara can do word wrapping, but I have yet to find a browser that supports it properly.
I've been looking for a solution about word wrapping in svg so many hours (or many days).
If you can in your app, edit your code to put some tspan, or any other method, go in it.
Text wrapping will be implement in the 1.2 version but except opera, no browser fully implement it yet (4 years, the specification are on the W3 ...).
Because I had to use some alignment settings, i couldn't use any of the code that many forum can provide (no foreign object, no carto script or anything).
If I post this message, it's just in order to be usefull to some other people when googling word wrapping svg because this post on the top result and in many case, this post doesn't help.
Here is a cool, easy and light solution :
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-dom-01-f.svg

Resources