Take a look at the screenshots. Even if the screen-edges-page looks odd in V9, the macro is still working as it should, so it’s ’just’ a cosmetic issue.
Ok, it seems to be impossible to attach screenshots with my phone. I’ll send them when I get home…
I don’t see the overlapping here.
pls run _SystemInfo and post back the results.
Ok, here you go:
SystemInfo MacBook Pro.txt (12.9 KB)
I just updated my Mac to 26.6, still not seeing it:
@dan is this something you can reproduce perhaps?
But, but… You don’t have any macro there. Copy / paste the macro I posted into the “Main screen Top edge”-field (for instance). Still nothing odd…? It should obviously look like the V8 screenshot - and not like in the buggy V9 screenshot.
I can’t reproduce it:
but it really looks like an Interface Builder XIB constraint failure on the “Top Edge” label and field. Bizarre.
I just took a look at the xib that governs that tab and it is not reporting any obvious constraint failures, but at the same time, all the constraints look very “old school.”
It’s odd we can’t reproduce this. Constraints are notoriously fragile and I’d really like to be able to reproduce this so I can rest assured that the fix works and doesn’t break under other conditions
These constraints are largely there to support Localization where the length of the label strings varies language-to-language). Don’t underestimate my ability to fix your issue and also mess up all users running in Japanese.
I can’t reproduce this issue. I suppose if Gijs can reproduce it, we can stumble through a fix here.
Oh I see what’s going on. You are both inserting newlines in there…or you are when you copy/paste from a PDF, which inserts them. I copied and pasted as plaintext which stripped the newlines. (I should never trust anything copied out of a PDF)
I can fix this…by stripping the newlines. Either that or adding a height constraint to the textfield.
I think I actually copy / pasted from my .pages-file and not from the .pdf-file. Anyway… Why is it working in V8 but not V9?
Great if you can fix it ![]()
Good question.
The way macOS interprets the files that define these interfaces (interface builder files) is dependent on the macOS deployment target (which minimum version of macOS that Rhino targets). That’s different between Rhino 8 and Rhino 9. We are slowly but surely migrating away from interface builder files toward our cross-platform solution, Eto.
The fix is in the pipeline. It just needs testing.



