VS 2010 seems to be updating my form's designer.cs file when I open the form in designer view.
For example, say I have a form with a label of type System.Windows.Forms.Label and I had created the label such that the designer file has (auto generated code)
this.myLabel.AutoSize = true;
this.myLabel.Font = new System.Drawing.Font("Tahoma", 8.25F,
System.Drawing.FontStyle.Bold, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
this.myLabel.Location = new System.Drawing.Point(**25, 63**);
this.myLabel.Name = "myLabel";
this.myLabel.Size = new System.Drawing.Size(**101, 13**);
this.myLabel.TabIndex = 1;
this.myLabel.Text = "A simple windows label.";
when I close out of designer view and open it again, VS 2010 will sometimes alter it to
this.myLabel.AutoSize = true;
this.myLabel.Font = new System.Drawing.Font("Tahoma", 8.25F,
System.Drawing.FontStyle.Bold, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
this.myLabel.Location = new System.Drawing.Point(**29, 78**);
this.myLabel.Name = "myLabel";
this.myLabel.Size = new System.Drawing.Size(**124, 17**);
this.myLabel.TabIndex = 1;
this.myLabel.Text = "A simple windows label.";
when I've not done anything other than open the file.
Does anyone know why this is happening? Has anyone else experienced anything like this?
Feature, not a bug. The form was originally designed on a machine that had its video adapter dots-per-inch setting at 96. Your machine has a different DPI, 120. Very easy to change on modern versions of Windows, you picked the 125% (Medium) setting in Control Panel + Display.
A different dpi setting affects the size of the fonts you use. There's one visible in your code snippet, it is 8.25 points. One point is 1/72 inch. So the text was originally 8.25 * 1/72 = 0.114583 inches high. With the dpi at 96, that's 0.114583 x 96 = 11 pixels. Note how this also explains why you got the extra 0.25 added to the point size, it made a nice round number.
But now your dpi is 120, the text will be 8.25 x 1/72 x 120 = 14 pixels. The text got bigger, your control needs to get bigger too or it will clip the text, shearing off the descenders.
This was done automatically when you loaded the form. The essential properties are AutoScaleMode, set to Font by default. And AutoScaleDimensions, you'll find it assigned at the top of the InitializeComponent() method. That's the one that remembered what the original DPI setting was.
This is going to happen on your user's machine as well. Do make sure that the form auto-scaled properly. You may have some trouble if you have controls that have a different font size. And just check the form back into source control so this rescaling doesn't happen again.
Related
The rich text in an NSTextView displays on my screen (27" Mac) a lot smaller than the font size would imply, although it prints correctly, and is the correct size if pasted in to another app (e.g. OpenOffice). TextEdit shows the same behaviour.
The following lines in awakeFromNib fixes this more or less exactly.
[myTextView scaleUnitSquareToSize:NSMakeSize(96.0/72, 96.0/72)];
myTextView.layoutManager.usesScreenFonts = NO;
So it looks as if the screen is using 96 points per inch. If I don't have the 2nd line, the text is slightly squashed up, and monotext mangled. Obviously I shouldn't hard code the scale factor, but where can I find the factor to put there? From [NSScreen mainScreen].deviceDescription ( a dictionary) I get NSDeviceResolution = {72, 72}", so it seems that's not what's being used.
I'm not sure this is wise, but you can get the "real" DPI from the display mode:
CGDirectDisplayID displayID = [window.screen.deviceDescription[#"NSScreenNumber"] unsignedIntValue];
CGSize size = CGDisplayScreenSize(displayID);
CGDisplayModeRef mode = CGDisplayCopyDisplayMode(displayID);
NSSize dpi;
dpi.width = CGDisplayModeGetWidth(mode) * 25.4 / size.width;
dpi.height = CGDisplayModeGetHeight(mode) * 25.4 / size.height;
CGDisplayModeRelease(mode);
[myTextView scaleUnitSquareToSize:NSMakeSize(dpi.width/72, dpi.height/72)];
myTextView.layoutManager.usesScreenFonts = NO;
Some display modes are letterboxed. These will presumably never be used as the general mode for the Mac GUI; they'd only be used by full-screen games. However, if you want your app to handle such a mode, it should account for the fact that the mode size does not correspond to the full screen size in one dimension and the DPI calculation above will be off. I don't think there's a direct way to figure that out. You have to examine all available display modes to see if there's one that's the same in relevant properties (size, pixel encoding, etc.) as the current mode but whose IOKit flags indicate that it's stretched (CGDisplayModeGetIOFlags(mode) & kDisplayModeStretchedFlag != 0) while the current mode is not. In that case, you probably want to assume the pixels are square and pick the smaller of dpi.width and dpi.height to use for both.
I just installed the sdk and run in creating sample app project.
I ended up with a folder full of icons and 3 classes that were to show me how things work.
The problem I noticed is that the code creates buttons that should have a background image but only the text is visible. Images are in the same folder and spelling is correct.
The auto-generated code looks like this:
playBtn = widget.newButton{
label="Play Now",
labelColor = { default={255}, over={128} },
default="button.png",
over="button-over.png",
width=154, height=40,
onRelease = onPlayBtnRelease -- event listener function
}
playBtn.x = display.contentWidth*0.5
playBtn.y = display.contentHeight - 125
Also the text doesn't change color. When I added another button below with my image below the auto created one I was able to see my tiny part of my image in the top left corner. The button was also visible when moving to net scene. How come?
To help solve your color issue you need to change the values. Corona recently changed to decimal colors, the range is from 0 to 1 versus 0 to 255. Anything over 1 will result in a 1 being used for the color.
So basically your colors need to be divided by 255 to get the proper value. You can either have the code divide it or you can divide the value yourself. You can read a post about it here.
I am trying to create a thumbnail from a PDF file, but I need it to be 300px*300px but no matter what I do I can not get the image to be the correct size. It always seems to be huge.
This is my code:
GhostscriptSettings settings = new GhostscriptSettings();
settings.Page.AllPages = false;
settings.Page.Start = 1;
settings.Page.End = 1;
settings.Size.Native = GhostscriptSharp.Settings.GhostscriptPageSizes.a2;
settings.Device = GhostscriptSharp.Settings.GhostscriptDevices.png16m;
settings.Resolution = new Size(72, 72);
GhostscriptWrapper.GenerateOutput(Path.Combine(FilePath, Filename), FinalPath, settings); // Create the initial thumbnail
Is there any way to output an image with the PPI of 300*300 ?
Cheers,
/r3plica
Looks to me like you are setting a resolution of 300x300. That is 300 dots per inch, which will give you reasonably large files.
You want to change the page size, which looks to me like you are setting to A2. An A2 page at 300 dpi will indeed produce very large output files.....
I have no idea how you would change the media size in C#. The Ghostscript command line switches you need are -dDEVICEWIDTH=300 -dDEVICEHEIGHT=300 -dFIXEDMEDIA
You say you are using a 'PSD' file, which would suggest Photoshop native file format to me, which Ghostscript won't interpret. Possibly you mean a PDF file, in which case you should also add -dPDFFitPage. If on the other hand you mean a PS (PostScript) file, you should set the PageSize Policy to 3 (select nearest media and scale down).
XNA apps (WP7 or WP7.5 apps) that run on a WP8 720p device will get automatically letterboxed so the 480x800 BackBuffer size stays the same (for compatibility I presume).
This would be fine, except there appears to be a bug in the XNA compatibility layer. The TouchPanel reports touch locations that are off by the size of the top letterbox blank area.
This has two problems:
The user's touches will appear to be off making gameplay and menu navigation difficult.
Because it is off in the negative direction, the user will be unable to touch things at the very bottom of the screen at all.
I tried working around the issue by just factoring in 53 / 2 pixel offset (53 is the total amount of extra space in scaled coordinate, divide by two because it is only off by one letterbox bar - the one on the top). This does correct the touch location, but because TouchPanel internally clamps negative values to 0, it means that there is still a dead zone at the top of the game (because -22 through -1 should be translated to 0 through 22, but if all negative input values are clamped to 0 then information is lost and everything in the negative range will translate to 22 always).
Has anyone run into this and found a way to work around it?
I'v even tried resetting the TouchPanel.DisplayHeight/Width to the actual 720p values of the device and somehow it gets reset to 480x800 by the next frame update.
I just got this working, the TouchPanel.DisplayHeight needs to be set to 853 (if you detect you are on one of these 720p devices) very early. I do it at OnNavigatedTo from the main Silverlight page (this is SL/XNA actually).
Next, you have to offset every touch location and gesture location by + 53.0f / 2.0f.
I'm not sure why this didn't work before, as this is the solution I mentioned above that didn't seem to work because TouchPanel kept resetting to 800 height.
But, I got it working in both a reduced repro (new SL/XNA app) and my main game app.
I was working on a game a couple days ago.
It was packaged for 7.1, but worked fine on the 720p emulator.
I don't know much about the compatibility layer, if it gets effected by the size of images then here goes :
I created separate images for WVGA, WXGA and 720p. Used them and found out about the letterboxing and decided to use 720p images for all.
Probably doesn't help but there you go anyway.
This is great solutio what I found from here: http://developer.nokia.com
It's not just fixing issue with touch but it also remove black blocks from side. Of course depending about your programn this can cause some more issues since resolution and screen ratio will change.
if (Environment.OSVersion.Version.Major == 8)
{
int? scaleFactor = null;
var content = System.Windows.Application.Current.Host.Content;
var scaleFactorProperty = content.GetType().GetProperty("ScaleFactor");
if (scaleFactorProperty != null)
{
scaleFactor = scaleFactorProperty.GetValue(content, null) as int?;
}
if (scaleFactor == null)
scaleFactor = 100;
if (scaleFactor == 150)
{
SharedGraphicsDeviceManager sdm = SharedGraphicsDeviceManager.Current;
sdm.PreferredBackBufferHeight = 800;
sdm.PreferredBackBufferWidth = 450;
TouchPanel.DisplayHeight = 800;
TouchPanel.DisplayWidth = 450;
}
}
I am having a problem when my program is installed to another computer, where its printer preference is different, where my data report accepts Letter size 8.2 * 11 in, because when the printer preference is different the data report well not show and gives an error saying the page width is larger than paper width, does anyone know how to fix this problem.
i tried this code but it didn't work
Printer.PaperSize = vbPRPSLetter
Check out the Microsoft KnowledgeBase article FIX: Error Message "Report Width Is Larger Than the Paper Width" When Showing Data Report in Landscape
When using the Show method of Data
Report to preview the report, the page
orientation defaults to the default
printer settings on the local
computer. Therefore, if the
orientation of the default printer
settings is set to Portrait of
standard Letter paper and your report
width is more than 8.5 inches wide,
the following error occurs: Report
Width is Larger than the Paper Width.
The solution appears to be setting Orientation before using the Data Report. Change DataReport1 to the name of your data report.
DataReport1.Orientation = rptOrientLandscape
DataReport1.Show
EDIT Another suggestion: Microsoft offer a free DLL that allows you to change the default settings for the printer. You could try using that free DLL in your project, then do something like this code below before using the data report. Microsoft say "this DLL is particularly useful when dealing with the Data Report, which reads the default printer orientation prior to displaying or printing a report."
Set obj = New PrinterControl
obj.ChngOrientationLandscape
-Can you just switch to a custom paper size?
Printer.PaperSize = 256
Printer.Width = 11808 '(8.2 * 1440)
Printer.Height = 15840 '(11 * 1440)
-Are you sure the error isn't related
to the maximum print width of the
report itself? Many printers have a max print width
that forces 1/4" margins on either
side of a paper. Which in your case forces your printable area to be 7.7" max. Quickest way to
check would be to temporarily set
the print wide to a lower value and
see if it works.
-Another possibility could be permissions to the printer. If it's a shared network resource it may be locked down and be rejecting the changes to the paper settings and throwing an inaccurate error msg.
To change Printer orientation at runtime, we need to install VB6 Service pack 6
Use this code
DataReport1.Orientation = rptOrientLandscape
DataReport1.Show
This will work fine