This is not exactly how my code is but for the sake of an example, I have a 3 column layout, first column being a col-md-3, and inside that I have 3 more columns, one which is col-md-1. However, because col-md-1 has a width of less than the padding (30px), the column to its right is now pushed to the second line.
to see my example, pull the divider until you are in desktop mode, and notice how the blue column is now on a separate line:
http://plnkr.co/edit/pQyjbrd7v4dWN4Ffkq9b?p=preview
Does this mean I can't have a column that small? I am coming from Bootstrap 2.x where the span1 had a width with a margin-left, so it used to work fine.
The short answer to your question is "Correct, can't have a column that small." You can't have a "1" sized column within a "3" side column for your purpose. The math is that the tiny column you're trying to display is only 2% (i.e., 8.3% of 25%) of the available page layout. On top of the Bootstrap 3 cols have a 15px left and right padding, which effectively wipes out that 2%. This is why you're seeing it wrap funny at anything less than about 1410 pixels, by my testing with your code. I don't know what you're trying to do, but the grid probably isn't the right way to do it for a so small a slice of the page.
Related
I am trying to find a (SoP)-expression using the embedded K-map. I have a box of size 4x4 which is a permitted use however I am having a hard time understanding how I could implement it.
To me the 4x4 box represents that the output is always 1 independet on any of the variables. Then I'd like to use the 2x4 box to the right and produce:
1 OR (Qc AND !Qd), but this does not produce the correct result.
I can see several alternative ways to produce the correct result. My questions are specifically:
Why can't I use the 4x4 box, or perhaps, how do I represent it correctly?
How do I know when I can represent parts of the output as a 4x4 box?
Perhaps Im missing something more fundamental.
Thx in advance.
The point of placing rectangles in a K-map is to eliminate variables from an expression. When the result of a rectangle is the same for the variable values X and X', then the variable X is not needed and can be removed. You do this by extending an existing rectangle by doubling the size and eliminating exactly one variable, where every other variable stays the same. For the common/normal K-map with four variables this works with every such rectangle because in a way the columns/rows are labelled/positioned. See the following example:
The rectangle has eliminated the variables A and B, one variable at a time when the size of the rectangle has been extended/doubled. This results in the function F(A,B,C,D) = C'D'. But check the following K-map of four variables:
Notice that the columns for the D variable has been changed (resulting in a different function overall). When you try to extend the red rectangle to catch the other two 1 values as well, you are eliminating two variables at the same time (B and D). As you cannot grow the rectangle anymore, you are left with two rectangles, resulting in the function F(A,B,C,D) = BC'D' + B'C'D (which can be simplified to C' * (BD' + B'D)).
The practice in placing rectangles in the K-map isn't just placing the biggest rectangle possible, but to eliminate variables in the right way. To answer your questions, you can always start with the smallest rectangle and extend/double its size to eliminate one variable. See the following example:
The green rectangle grows in these steps:
Start with A'BC'D'E
Eliminate the (only) variable A by growing "down", resulting in BC'D'E
Eliminate the (only) variable D by growing "right", resulting in BC'E.
But now, the rectangle cannot grow/double its size anymore because that would eliminate the variable E, but also somehow eliminate the variable C. You cannot eliminate the variable E, because you have 0 values to the left of the green rectangle and 1 values to the right of the green rectangle (all in the left half of the K-map, where you have the value C'). The only way to increase/grow the rectangle is to get the "don't care" values to eliminate the B variable (not shown here).
The overall function for this K-map would be F(A,B,C,D,E) = C'E + DE' + CD' (from three 2x4 rectangles).
This is a bit of a long-shot. I really don't know where to ask this question.
I've been trying out CodeConnection + MakeCode with Minecraft and I haven't been able to figure out if there is correct way to place half-slabs at 0.5 step y axes increments.
I tried using a line between 2 points, but it left gaps between each slab.
If I try moving up 0.5, then it rounds it up to 1, and again leaves gaps.
It appears that all of the builder functions seem operate at a resolution of 1 block. However in-game I can obviously place slabs in 0.5 block increments to make stairs etc.
Blocks only exist at integer coordinates. Half slabs that exist in the top half of their space are still at a full integer coordinate. They just have a BlockState value of bottom=top (or top_slot_bit=true on Bedrock, represented by the integer value 8 as a bitflag, eg: 0b1... where the . bits are the integer representation of what type of slab (wood, stone, quartz...)).
What you're looking for is this widget, under Blocks:
You can set the block and then an integer representation of the desired data value (see the wiki on data values) in the numerical slot. This widget can then be dragged into the (block) portion of any block widget:
You'll probably have to some variable fiddling to get the data value to swap back and forth as you need it to, but that should solve the hurdle you've been facing.
I am having trouble preventing the text inputs from overlapping the footer button.
The footer has been anchored to the bottom of the screen. All the elements up top (logo, title label, and 2 input boxes) all have relative constraints. I try to add a constraint between that last input and the footer button but it pushes the footer off the screen on the smaller iphone.
What do I do??
https://github.com/civilordergone/taskfort_ios
Your issue seems to be in landscape only (I ran your code), where you have, for example, 320 points of vertical space, and an image (128pt), a text label (120pt), two text fields (30 each, for 60pt in total) and a 30pt button at the bottom. Already that's 338pt used, and we haven't accounted for the vertical spacing between your objects.
There simply isn't enough vertical space for all of these items to be vertically positioned while retaining their heights, so something has to be flexible: something has to be able to be vertically shrunk/compressed. Your logo and app name (Taskfort) are two candidates.
Here are some of the changes and/or points of consideration:
An ImageView with a height and a width equality constraint will always be that size, but for your layout, it has to be able to be compressed. I removed the height & width constraints and added an Aspect Ratio constraint, so the logo keeps its aspect ratio, but can now scale. I added a relationship constraint between the logo's left side and the left side of the Taskfort label.
The image has a relationship to the top of the screen, saying it must be equal or greater (not less than) to 0. This just means "the image can't be pushed off the top", which "less than" would allow it to be. (For example, if the image is pushed off the top by -40 points, that's still "less than 20").
The image has to be allowed to be vertically compressed. There is a property for "Vertical Compression Resistance" that was 250, and is now 249. By setting it to 249, we're saying "If something has to give way, vertically, this object can be compressed." Since we defined an aspect ratio constraint, if it does get compressed vertically, it'll be reduced horizontally by a proportionate amount so as to maintain the proportions of the logo.
To prevent the text fields from overlapping, their relationships are set to "equal or greater than". Same for the Username text field to the label.
The challenge was in defining the relationship between Password and the Create Password button at the bottom. I added a constraint that says their vertical distance must be greater than or equal to 20. This has a priority of 1000 (by default), so at all times, you get 20pt or greater between those two. Without this, your password field and your button overlap.
While step 5's constraint solves the overlap problem, it creates a new one in portrait orientation, where the password is now 20pt from the button, instead of being lovely white space. To fix that, we add a second constraint between the password field and the button, and specify that the vertical distance is to be 228pt between them both. Now that creates a constraint conflict because you now have two constraints that are both trying to define the vertical relationship between the button and the text field. The 20-pt one is required, it has to be there. But the other one is just a "nice to have, if we can fit it".
So you set the priority of the new one (the 228pt) to be low, such as a Priority of 250. Then the layout engine will use the required one (must be 20 pt or greater) and then it sees the other one ("make them 228") and it tries to do that. If it can't, such as in landscape, then it doesn't do it and doesn't complain, because you have the other constraint already that provides positioning information. If you're in portrait and you have enough space such that it can also apply the low priority constraint, then it'll do that too, and your portrait layout now gets a bigger gap between top and bottom.
When testing these layouts, use the Assist Editor in Preview split-screen mode so you can see the affects of your changes without needing to run the simulator. Here's a guide on that.
Sounds like you're using an equality constraint, such as "the distance between lastInput.bottom and footer.top equals 20". Instead, try an inequality operator, such as "the distance between lastInput.bottom and footer.top is equal or less than 20".
The attributes inspector for a constraint can let you change an equality to an inequality. Alternatively, you can double-click the constraint line (the UI in the storyboard editor) to get a quick pop-up for that.
I’m trying to put together what seems to be a simple case of two NSTextFields with dynamic width and fixed spacing in between. I cannot figure out an effective way to do so though.
I’m looking to get something like this:
The blue boxes are the NSTextFields. When more text is entered into one, it should grow and thus make the other one shrink, maintaining the lead space, trailing space and the spacing in between the fields. The first one should take the priority if both of the fields have too much text. Each field will also clearly have a maximum and a minimum possible width it can reach.
How would I go around handling this, preferably utilising IB autolayout as much as possible?
It seems to me that all of constraints you mentioned directly translate into interface builder --
First view has width >= something.
First view has width <= something
Same for Second view.
Space between views is fixed.
Second view wants to be as small as possible (have its width at 0) but this has lower lower priority than the previous constraints and lower priority than inner content size constraints.
The code I had to add to my view controller, after applying the constraints as per the ilya’s answer:
In controlTextDidChange (_controlWidthConstraint refers to the fixed width constraint of the input; it’s probably 0 by default for the second input):
// Get the new width that fits
float oldWidth = textControl.frame.size.width;
[input sizeToFit];
float controlWidth = textControl.frame.size.width;
// Don’t let the sizeToFit method modify the frame though
NSRect controlRect = textControl.frame;
controlRect.size.width = oldWidth;
textControl.frame = controlRect;
_controlWidthConstraint.constant = controlWidth;
The key lies in invalidating the intrinsicContentSize for the text field when text is input.
You can check a sample project here, to get you on the right track.
I have a grid that needs to show 1m+ records if necessary. The user may filter down if needed but the initial view will attempt to show a grid and associated scrollbar with 1 million or more rows. I am using dojo 1.4.3.
I have it set the grid up to use a QueryReadStore, and my grid config has rowsPerPage as the default 25. Autoheight is not being used, the height of the grid itself is static.
What ends up happening in FF8 is a blank grid renders after the data fetch. (edit: Following scientific notation tidbit is untrue, FF deals with this properly) It appears the problem occurs because the height is being set with scientific notation, so I'll see the div with class dojoxGridContent have a style="height: 3.2e+7px;width:6039px". I assume this is the result of 32 pixel rowheight multiplied by 1000000 rows. Even if this is fixed, setting the element height to 32 million results in a 0 height div. The limit appears to be somewhere between 17 and 18 million pixels for FF. Chrome's limit appears to be between 130 and 140 million. Didn't check what IE's is.
This blank grid behavior is not exhibited in IE or Chrome, because they neither return scientific notation values(edit: scientific notation seems ok) nor have such a low(?) element maximum height.
I can see a one solution that I'm not too sure how to implement, and that would be to fix the scientific notation pixels problem for FF(edit: This is not an issue, FF seems to be able to interpret this) and cap the 'numRows' attribute either at the store level or the server level to some value that will always result in a valid height based on browser and version.
Would love to hear other suggestions and any experiences others have had with large datasets and grids.