This has me stumped. I have a view with two child labels as shown here...
Here are the constraints for the entire view:
All of those constraints have a weight of 1000.
The problem is the orange label has it's horizontal ContentHugging set to 1000 whereas the blue label has its horizontal ContentHugging set to 250, which, AFAIT means the orange label should hug its content causing the blue label to expand to fill the area thanks to the constraint between them with a length of zero. Yet I'm seeing the exact opposite. What gives?
Settings for the orange label
Settings for the blue label
So what the heck am I missing?!
Update
After further research, this seems to be either a corrupted NIB file, or an issue with Interface Builder itself. I say this because I created a second NIB with the exact same settings as above, but this time it worked as expected. (I even copied the views themselves from one to the other.)
To be sure, I went through everything view-by-view and compared all values and constraints and it all looked completely identical.
While I could open up the nib itself and compare the raw text to see if there was something odd, since the new one works, I'm considering this as an anomaly, meaning unless someone can point out a mistake made above that I'm still not seeing, I will close this out as such.
Related
I can share the code if needed but it felt like a lot to share to start, so I'll try to explain narratively. I am creating an interface to display network data (as you might have guessed from the title). My first issue has been going on for a few days where visIgraphLayout is not laying out my visual correctly. Regardless of using "full" or "square" as the "type", the network map extends beyond the edge of the display space. When I resize the interface window, then the map will snap to full. Why won't it simply resize automatically? If it matters, I do have the output space in a box element. Also, I have the layout styles working off radiobuttons, and when I switch between styles the map goes beyond the edges again.
Part 2 begins. While the above problem is annoying, it was livable. However, a new wrinkle popped up. I added some font size control to my visNodes code - i.e., radiobuttons set to switch between off (0), small (5), standard (14), and large (40) font size options. Once I implemented this code, when I resize the interface window, now the network map disappears completely after initial load. If I select a new label option, it will redraw but beyond the edges of the space.
All the issues resolve themselves if I ditch the visIgraphLayout, but then I lose the layout functionality which I really like.
I hope this is clear enough. I really appreciate any insights the community might provide. Be well.
I think I have figured out an answer. Long story short, certain pieces didn't work and play well with others. Went through and build it again, and all it good.
Cheers.
I've been using the react-devtools to detect any unnecessary component updates, however I'm not sure I fully understand how it works.
I can identify the various components that got updated by the added borders indicating that they got updated but I'm not sure what the various colors of those borders mean (I've so far seen cyan and light green colors).
I'm not familiar with this either, but I'll trace through the code! :)
This is the component that renders the "Highlight Updates" toggle. It calls a changeTraceUpdates method in the main Store which sends a message through the "bridge" to activate the TraceUpdatesBackendManager. Poking around that file, we see a couple of classes with names like "presenter" in them; I assume one of these is what actually draws the border. In particular, TraceUpdatesWebNodePresenter looks related because it defines an array of COLORS. It looks like these colors are chosen based on a "hit" attribute, which a quick search suggests is set by TraceUpdatesAbstractNodePresenter– and gets incremented each time an element is "presented".
Reading between the lines then, I assume this means that components that render less frequently will be outlined with "cool" colors (blue) and ones that render more frequently will be outlined with "hot" colors (red).
First of all, I must mention I have duplicated the constraints in a new project and have not been able to duplicate the problem. The problem occurs in a complicated storyboard project I've been working on for months.
For simplicity's sake, this is basically the issue:
I have a Container View inside of the default View inside of a View Controller. The Container View has constraints to the Top, Bottom and Trailing edges of it's superview. I have two "equal widths" constraints connected between the superview and container view. One is equal to the superview, the other is proportional to the superview with a 0.9 multiplier in the constraint.
I have a button superimposed on top of the container view which alternates between the 2 "equal/proportional widths" being active (I've currently deleted all the other objects in the View Controller for simplicity, to try to isolate what is causing the problem...
When the button switches the "equal widths" constraint to the 0.9 proportional width constraint, it "pushes" the container view away from the trailing margin (by 12 points), while it also shrinks the container view by 10%, as desired.
I've been working on this for hours, so far to no avail... out of desperation, I added an extra trailing edge constraint to switch on and off, with an extra 12 points to compensate for the shift when the proportional width is switched on. The default trailing (to superview) constraint is set at -20, as I increased it to -30, -31, -31.5 it got closer and closer to looking right, but when I put it's constant at -32, it jumped again, about 12 to 20 point, off the edge of the trailing margin! I know this is not a good way to try to solve this problem, but I wanted to mention it, in case it may be a clue for someone more knowledgable than me as to what is causing the problem..
Thank you for any help you can offer!
UPDATE:
The problem seems to be stemming from a conflict in the VC embedded in the container view. The Height of the embedded VC was 720, while it's container was 720... but even after I change these Heights to match, either way, I get the same problem...
The problem seems to disappear if I delete the embedded VC and just use the container view, but this is not a solution since I need the content of the embedded VC...
One last note, I have a similar method in place with a button press which changes the height of the embedded VC, but with no problem..
I have experience similar constraints problem before, without seeing the storyboard I cannot pin point the exact cause but you can try the following:
Double check your constraints are connected to your codes, even if they are not the codes will compile and run but with no effect.
Look out for logs of auto layout breaking constraints, there might exist another constraint that held your view in place cause the newly activated one to be broken.
If both are not the cause, also check if the button is calling the right action.
In any case, if my tips did not help at all, you might need to provide more information or a screen cap showing the view and it's constraints for a better understanding of your problem from my end.
I solved it!
So, as I suspected in my update, the problem stemmed from something not syncing up in the constraints between the container view and it's embedded view controller. In the container view, as mentioned above, there was a constraint for the trailing edge of the superview and 2 for the width I was switching between with a button. The embedded view controller's view was had a leading constraint to it's superview. Once I deleted that and switched it for a trailing view as well, the problem was solved!
Lesson learned: If you are going to alter a container view with multiple width or height constraints, make sure have the same side constraint in the container view and the embedded view's contents (top or bottom for y-axis, leading or trailing for x-axis).
I'm trying to zoom QQuickPaintedItems, such that things gets larger, but drawing quality does not get worse (i.e. painting is re-triggered as items gets larger).
setScale method is similar to what I want to get, but the item content is not scaled, therefore it looks bad.
setContentsScale, instead, will scale the content and trigger a re-paint, therefore the quality is high, but unluckily the content becomes also bigger than the item
I would like to obtain a combination of the two, but I can't get it to work. I tried using setContentsSize, but it's not really clear what it is used for and, moreover, I tried changing it to some random values, but I'm not experiencing any visible difference.
What is the purpose of setContentsSize?
Can it be useful to implement the zoom I'm looking for?
Is there a better alternative?
EDIT:
I tried experimenting a bit, but still I didn't find an answer.
A sample code to demonstrate my results is here, while a screenshot of what I get is the following:
I cannot understand why the blue rectangle is large as the yellow one, but the painting goes outside of the blue one: if you watch carefully, you can also see that the text is on a single line and it's not wrapped.
What's going on?
The problem is that QQuickPaintedItem is affected by a bug regarding this matter, see here and here.
As reported in the documentation, scaling happens both on content and on painter, therefore the blue rectangle is as expected (consistent with the doc), but not really useful.
To fix it, it is required a bit of tweaking: width() and height() shall be used to get the current item size, instead of contentsBoundingRect(), and the sizes must be set depending on the scaling factor.
I have a problem with redrawing in flex 4. I have a spark titleWindow, and if i drag it faster, it looks like it's mask is one frame late after the component.
it's easily visible with 1pixel thin border, because it becomes invisible even with slower movement.
You can try it here (what is not my page, but it's easier to show you here than uploading example):
http://flexponential.com/2010/01/10/resizable-titlewindow-in-flex-4/
If you move in direction up, you see disappearing top border. in another directions it's not that sensitive as it has wide shadow, and it's not very visible on shadow.
On my computer i see it on every spark TitleWindow i have found on google, although it's much less visible with less contrast skins, without borders or with shadows.
Do you see it there? i had never this problem with halo components. It's doing the same thing with different skins. I tried to delete masks from skin, cache component, skin even an application as bitmap with no success.
I also turned on redraw regions in flash player, and it looks like it's one frame late after titlewindow too.
Does anyone know why is it doing this or how can i prevent it?
Thank you
UPDATE:
no answers? really?
I have been facing the same problem and I was really pissed that I couldn't find any answer.
The problem with me was, that I tried to center the component "component.x = (parent.width - component.width) / 2" and then draw that component programatically. The problem was, that component.x is a Number which can lead to floating values like 10.5 or similar. And it looks like that bitmapFill function rounds floats DIFFERENTLY than drawRect function, which makes exactly the 1px line around the objects (but ONLY when parent.width is an odd number). Strange thing for me was, that I only called the Draw function once, but still this line keep recurring ...
Doing Math.floor(component.x) solved the issue.
P.S.: I think that you can also help your issue by setting cacheAsbitmap=true on the dragged object ...
Cheers,
Jan Prazma