I try to setup UltraMon with a really big width and height for my Safari on Windows.
See capture : http://cl.ly/de21e9cd2cf4f265efc4
The problem is that the width and height seems to have a max value that I would like to change.
I want UltraMon not to change my width and height, even if they are bigger than the screen resolution.
Windows doesn't allow that, according to the developers of UltraMon.
See http://www.realtimesoft.com/multimon/forum/messages.asp?tmpl=UltraMon&Topic=10795#39510
Related
We are trying to set up screenshot tests to automate UI/ layout regression testing by comparing screenshots against an expected set of screenshots. We are using testcafé for that but we are struggling when scrollbars come into play for full-page fixed width screenshots:
const testcafe: TestController;
await testcafe
.resizeWindow(1024, 768)
.takeScreenshot({
fullPage: true
});
This will result in a screenshot with a width of 1003px (not 1024px!) and a height of 1546px. Nonetheless, the screenshot still contains the vertical scrollbar which is surely not out of coincidence 21px wide. It's neither full page as few pixels are also missing at the bottom of the page which most likely does actually result in the vertical scrollbar.
When trying to workaround the reduced width by adding additional pixels (21 to be exact), the screenshot is indeed 1024px wide and has a slightly reduced height of 1510px (as something on the page is not required to be wrapped anymore). It's still missing parts at the bottom of the screenshot and it still has a scrollbar.
const testcafe: TestController;
await testcafe
.resizeWindow(1024+21, 768)
.takeScreenshot({
fullPage: true
});
Now it gets slightly more weird: The behavior just described continues up to a width of 1024+21+20 px. Screenshots have a width of (1024-21) +21+20 px, a height of 1510px and scrollbar. Starting from 1024+2*21 though the vertical scrollbar disappears, the screenshot is complete also at the bottom with 1510px as the correct height (as again something else on the page doesn't have to wrap anymore) - but unfortunately I do have a screenshot with a width of 1045px which is not of the intended width of 1024px.
If I specify resizeWindow with a width of 1024px I do expect a screenshot exactly of that width if it does include a scrollbar. If testcafe thinks it has to take the screenshot without the scrollbar and reduce the screenshot to a width of 1003px it's also fine with me - but here I guess it has somehow considered the scrollbar but still not actually cut it off.
The same mechanism for a page which content doesn't require the height of 768px, in other words doesn't have a scrollbar to begin with, the screenshot has a width of 1024px without any "correction".
Few versions if relevant:
node: v14.16.0
testcafe: 1.10.1
browser: Chrome 89.0.4389.72 running on Windows 10
Do you have any further ideas?
I'm used to using Titanium.Platform.displayCaps.platformWidth all over my app to get the width of the window.
But with SplitView on the iPad Titanium.Platform.displayCaps.platformWidth still returns the total screen size of the iPad (as it probably should).
How can I determine the actual available screen width for the app while using SplitView?
I don't mean SplitWindow BTW. This is in regards to SplitView where you can line up two different apps next to each other on the iPad
Thank you!
you can get the width your uiElement using postLayout event
var uiWidth;
myElement.addEventListener('postlayout', postlayout);
function postlayout(e){
uiWidth = e.source.rect.height;
myElement.removeEventListener('postlayout', postlayout);
}
An easy way to determine how wide a certain view is, is to use toImage() on the UI element, and then get the size.
So... when you do
console.log($.myWindow.toImage().rect.width);
You should get the width of the window. Which should be the width allocated to your app.
My VB.Net application is using anchoring to force certain controls to resize to their container, eg a list box on a form. This is all pretty standard and easy to do. However having just released the application into production I've found that on one user's computer the anchoring seems to just be ignored. She has Windows 7, as do I.
So far example what should look like this:
instead looks like this
I asked her to try a higher resolution on her screen but that didn't to help.
On one of them I was able to fix it by manually setting the width and height in form load properties of the control instead of anchoring it, but it seems a bit backward.
It looks to me like the form has been resized to be too small for the anchoring to work correctly. Set the .MinimumSize property of the form to ensure the form does not get too small for your layout.
Older staff sometimes reduce the screen dpi to make text easier to read, which means the screen may not be big enough to display the form. To fix this, set the screen dpi back to something reasonable and increase the text size for readability.
Turned out to be that the display issues were caused by user having the "Font Size" setting on her computer set to 200%. To be honest I didn't even know you could do that.
I want to fit the Image + Label into Scrollable View.
It looks like so My setup
So trouble here is that width of the picture and the label did not match the screen width.
I tried to change the UIImageView width from 400 to 300 or so, BUT those changes either wont take the effect(if above 300), OR those changes make label disappear (with width setted up on 300 or below). Observe.
Funny thing is - label actually appears when you see view hierarchy, even though it looks kinda distorted. But no label on the iOS screen for you, sir.
I also tried to set equal width and height from the superview, but this option just disabling scroll, making view strictly fit the screen (label appears to be cropped)
I want the label to be nice and scrollable, but I also want to see it on the screen. Too much to ask?
EDIT: I just tried removing Auto-layout and got the same as with auto-layout. (click "Observe" link to take a look again, exact same situation) Could somebody explain why?
This is quite a simple fix. For the image, you should use equal width & center horizontally; however, make sure you use a fixed width. For the image to look nice, play with the scale modes - I find Aspect Fit/Fill work best.
The label should also be equal width & centered horizontally. You may need to calculate the height of the label programmatically if the text isn't always going to be the same size.
So the answer to my particular question was - shortening the actual text that is passed to the label.
Apparently UIScrollView can't handle stuff with crazy abnormal heights (I was passing a huuuge text to it) So in my particular situation solution was - shorten the text. Now it works like a charm (even though I still need to play a little with constraints to get rid of the warnings and stuff)
This may sound strange, but I don't understand how designers determine the image widths in their bootstrap layouts.
Consider the following template:
http://startbootstrap.com/templates/blog-post/
The 900x300 placeholder image is clearly not 900 wide on desktop 1080p monitor. It only ever gets shown full size when the browser is around 1000px wide.
Q) Am I being dense here? How are these widths determined/decided upon?
This is important as I want to make some designs using bootstrap, but obviously I want to make sure I select appropriate image widths.
Many ways to do this, but simplest is to use Chrome's "Inspect Element".
1) Right-click on photo and choose "inspect element". Scroll down until you see diagram of it's dimensions, padding etc
2) Adjust browser width to max out photo width (in your example it's between 990px and 1200px)
2) Keep editing the the placehold.it image-width until the inspector diagram stops changing photo width (see attached photo). This tells you the max threshold, in this case is 940px.
FYI, you can also try to determine knowing your column widths, padding, margins, and assuming you have properly reset nested column padding, but there is a lot of assumption and calculation there, so I tend to use the inspector method, at least to confirm.