The MonoDevelop window will not get any smaller than the screenshot, posted. I am using it on a different computer than I have before (now using Windows 8.1), and have not encountered this problem until now (old computer was on Vista). I tried using Window's "drag to the side and snap to half the screen" feature. All it does is match the height with the screen height. The width remains obnoxiously large. Please, help.
The smallest that MonoDevelop will go
The min. width and height of the Workbench/IDE is:
const int MinimumWidth = 800;
const int MinimumHeight = 540;
You would need change it in source and re-compile MonoDevelop.
Located in DefaultWorkbench.cs
Related
I'm developing an app for OS X which shows a small window (uses Auto Layout) when exiting. The window's size is about 550 x 290 pixels and it's fixed.
But I'm facing a behavior that seems pretty strange to me:
Starting the app on OS X 10.7: the size of the small window is about as triple as large as it should be (width and height)
Starting the app on OS X 10.8: the width of the window fits but its height is still about as twice as it should be
Starting the app on OS X 10.9: the window has the size as I've designed it
Starting the app on OS X 10.0: same (correct) behavior as with 10.9
I've re-set all constraints to correct settings (Xcode shows no layout issues). Can somebody give me a hint what might be happening there?
I'm absolutely sure that there are no other (conflicting or modifying) constraints within the view.
Update
Below you can find an image containing all constraints of the window. The constraints of the window itself (min and max size) have been set to the current (expected) size.
The image on the left side has been pinned to the bottom, the left and the top and its scaling behavior has been set to proportionally down. So the image should not be the source of the issue.
I've found a solution that works. I think it was a combination of the 2x image within the assets catalog (caused the doubled height) and the labels within the view. The labels contain so much text that they either have to wrap it automatically or stretch them until the content fits (Lion and Mountain Lion seem to do so).
I've added the width constraint to both labels and fixed it at its current value (as given in the Interface Builder). This works for me as AutoLayout seems to keep the label's width and wraps their content (as expected).
Thanks a lot for the hints.
When developing using cocos2d-x 3.x for a device, it automatically sets the GL view to fit the device. In VS2012 on windows, it creates a seemingly-arbitrarily sized window. How do I set the size of that window?
My solution was as follows.
In AppDelegate.cpp:
bool AppDelegate::applicationDidFinishLaunching() {
auto director = Director::getInstance();
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLView::create("My Game");
glview->setFrameSize(800, 600); // or whatever
director->setOpenGLView(glview);
}
...
}
In my particular use case, I'm setting the window sizes to various resolutions and aspect ratios to test my layouts. I'm sharing Q&A format because I couldn't find a straight answer to this anywhere.
+1 to Tom. Also, I would just like to share my answer and experience to everyone.
Remember, do not set the screen size "AFTER" the director set the GL view. This causes some problem with bounds detection on some nodes most notably cocos2d::ui::Button and other ways on how create buttons. I am using cocos2d-x v3.6
Check my answer here:
cocos2d::Menu click detection is a bit off to bottom left whenever using a custom window size
Doing this way will cause some problem:
auto director = Director::getInstance();
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLViewImpl::create("My Game");
director->setOpenGLView(glview);
}
director->getOpenGLView()->setFrameSize(width , height);
Clicking the button, doesn't kick in the callback. Which is frustrating. Probably out of your frustration as well you click all through out the screen and notice there are some part of the screen (most likely bottom left part) which triggers the callback as if the bounding box of the node lies there. It doesn't even match the position and the size of the node in question. I can reproduce the problem whenever I change the screen size like the one I describe above. So never ever do it like that.
Tom's answer is the correct way of changing screen size.
I hope this will deter anyone doing it this way. I swear to God, this post could have save me heck of time solving this.
Cheers!
I have a script that positions the popup at the bottom right corner of the users screen every time. However, IE8 could care less about the fact that there is more to the window than the viewport. How do I get the size of that in IE8?
var popUpWidth = window.outerWidth; // does not work in IE8!
var popUpHeight = window.outerHeight; // does not work in IE8!
IE8 doesn't have the outerWidth / outerHeight property, try instead:
document.documentElement.clientHeight;
document.documentElement.clientWidth;
Here's an example http://james.padolsey.com/javascript/get-document-height-cross-browser/
Set the window to a given size. Obtain the size of the client window. This will be smaller by the amount of window chrome. Use the difference to calculate the window size for any client size.
The initial size is completely arbitrary but the current client size plus an optional fudge factor will cause the least change on screen.
My main NSWindow contains UI restricted to some size range, otherwise it can get corrupt. I restrict the window to a size-range using
[myWindow setContentsMaxSize:maxSize]
[myWindow setContentsMinSize:minSize]
This works fine for user dragging of the edges or size-box.
When the user presses "fullscreen" button, Lion starts an animation that will
Shrink the window below its current size,
in several steps, increase its size until it reaches the full-screen representation size.
If the window started in its minimal size, this animation will shrink it BELOW the defined minimal size, and will corrupt my UI beyond repair (user needs to relaunch the app). My views are receiving setFrameSize: with unsupported size.
My questions
Can this be considered a Cocoa bug?
Am I doing something wrong in my view hierarchy?
Can I somehow prevent the corruption, without replacing the OS standard animation for full-screen?
Why doesn't the standard animation base on a "snapshot" of the window contents, instead of
live-resizing of the whole view-hierarchy throughout the animation? This is surely not efficient.
Is there a simple way to apply another standard transition that will
be non-destructive for me?
Can someone "spare" a few lines of code that will do a simple linear resizing animation that will NOT go below minimum?
Thanks.!
I've also investigated fullscreen animation behaviour and here is how it works:
It is also based on taking snapshots of window's content, but with some improvements. It takes several snapshots on some control points: 512, 1024, 2048 and so on.
In my case to enter full screen 2560x1440, my 400 pixels wide window took 512 pixels snapshot, then 1024 and then 2560 wide snapshot. I don't know whether this behaviour is default for all cases, but this is the result of my own investigation.
On the issue with setting min/max window size:
Minimal window size set up in Interface Builder works for me, but max constraints not. I'm currently working on it and this documented method should work for you:
Place this code into your window delegate.
static const NSSize kWindowMinSize = {100, 100};
static const NSSize kWindowMaxSize = {100500, 100500};
...
- (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize
{
frameSize.width = MAX(kWindowMinSize.width, MIN(kWindowMaxSize.width, frameSize.width));
frameSize.height = MAX(kWindowMinSize.height, MIN(kWindowMaxSize.height, frameSize.height));
return frameSize;
}
Hope this will help you!
I want to add a CComboBoxEx on my form, but I have to align it with other controls and make it the same height.
The problem is that I can't find which is the correct way to get the height of this control.
If I set the window rectangle, that affects the drop down listbox. If I force it to be some fixed size, and the content inside the combo is higher, the control gets clipped at the bottom.
Is there a way to calculate how big the ComboBoxEx will be, based on image and current DPI settings? So that I could at least expand the other controls if I cannot adjust the internal padding of the control. MSDN doesn't touch the sizing issues at all as far as I've looked.
ComboBoxes set the height of the control automatically, and as you've discovered, trying to set your own height actually affects the height of the drop-down list.
To get the real height of the control (so you can resize your other controls) you can use GetWindowRect:
RECT rc;
GetWindowRect(hWndCombo, &rc);
int iComboHeight = rc.bottom - rc.top;
I don't know of a good way to change the height of the Combo control itself, and frankly I don't believe it's possible at least without lots of subclassing. I have implemented my own combo-style control because of this.
Although it probably won't help, you may also like to have a look at the GetComboBoxInfo() function to see if that provides any useful information.