I am making a board game using C# in Visual Studio.
I am using pictureboxes as pieces and I change their location according to their dice roll.
The locations are really important to my game.
But for some reason, when I test the app, the sizing and locations are way different than in the design view while editing (see images, espacially the image differences are visible)
Is there any way to get around this and get better sizing/locations on my application?
The design view while editing
The app while testing (Started)
Related
so I'm making this 3D TTT game and I'd love to add a 3D interactive cube for live feedback, because the game as it is may be hard to grasp by greater audience.
I've chosen Visual Studio 2013 for my project and I write it in C#. The game looks like 7 isolated squares containing 7^2 buttons. My idea is to add a 7^3 cube of 343 cells for better navigation to the form. Obviously, each cell within the cube would have to be linked with each WF button.
So far I've spent goodly time on the internet and even my IT teacher was unable to provide this answer, so I come to you. Is there any way to do it?
You could try SlimDX: http://slimdx.org/ It is a free open source framework that enables developers to easily build DirectX applications using C#
OpenTK http://www.opentk.com/ is another option.
I had been developing WinForm apps in a long time. I just recently bought a Surface Pro 3 to serve as my new development PC. Unfortunately I noticed an issue with the GUI editor. The some of the sizes of the controls don't match with what appears in the GUI editor and with what appears in the actual running application. For example, the sizes of my panels don't follow what it looks like in the GUI editor when I run the app. They usually increase in dimension. I am not really sure if it is a VS issue or maybe it has something to do specifically with using Surface Pro 3?
To demonstrate what I mean consider the following screenshots. Notice the difference in the size of the Menu Bar in the GUI Editor and in the actual application.
If you want to prevent your app from changing size, you can make it independent of DPI settings. Your app will be pixel perfect but on high resolution screens may be too small.
All you have to do is to change AutoScaleMode property of the main form and set it as None.
I know this is an old thread but I was experiencing the same issue... I found a workaround which you may find useful...
After trying a few things it became obvious to me that windows 10 was attempting some "intelligent" resizing of forms under Windows 10 on the surface pro (I am using a surface pro 4)... I am not sure if it is a win10, high-res or surface pro issue.... whatever it is it was messing up my control sizing, placement, anchors and resolution.
I found that if I made a note of the intended size of my form in the designer and then manually set this in code at the end of my Form_Load event, it would override this unintended behaviour and I ended up with my originally intended form size and control placement, I also needed to re-center the form in the parent/screen to get the desired result (of course only if that is the intended start-up position for your form)
The code that worked for me (at the end of the Form_Load event) is...
this.height = 800;
this.width = 600;
this.CenterToScreen();
I hope this helps somebody, I was pulling my hair out for a while!
It has been a while since I posted this question and I kinda forgot about it. I thought I should share my recent findings for those who will find themselves in this same predicament.
I learned that the discrepancy between the GUI editor and the actual running app was because of the super high DPI scaling of my Surface Pro 3. Visual Studio was automatically running at 216 DPI (225% display scaling) compared to the usual 96 DPI (100% display scaling) of common computers. My workaround back then was to simply adjust my controls accordingly thru trial and error and to anchor most of them between the GUI editor and the running app. Eventually, it became less of an issue since I moved on to a normal desktop with a normal screen for my regular software development. Moving forward, I recently stumbled upon a Microsoft documentation regarding Automatic Scaling in Windows Forms. It explains the issues with multiple DPI scaling for Windows Forms. It also includes this bit about the DPI scaling issue of Visual Studio:
With the extreme differences in display DPIs, especially in modern 2-in-1 devices, this can still happen with the most current versions of the .NET Framework and Visual Studio. To address this in a team using different DPI displays, make sure Visual Studio always starts in a non-DPI-aware mode, so the Windows Forms designer always bases the layout calculation on 96 DPI.
The solution they suggested is to add or import a registry value that disables Visual Studio's High DPI awareness:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
"dpiAwareness"=dword:00000000
I tried it and it definitely works. I hope it helps you too. :)
I have just started to develop in universal app. I have developed app in Windows 8 store apps and also developing Windows Phone 8 and Windows Phone 8.1 (SilverLight) Apps. Question is related to universal app in Windows and Single UI which is created in App. Share folder.
1 For web there is word like responsive UI. to create there is media query to write css.
I know css is same as we can create resource with for xaml . I can get resolution form c# and I can create different UI for different resolution and I can visible collapsed according to resolution but is there any single way which automatically adjust according to design.? ( this question is related to data binding controls specially...)
There are several techniques to adjust the page's design to the size, shape, and resolution of the window. These are usually used together.
The first is to use dynamic layout controls instead of hard-coding positions. For example, use a Grid control with * columns to split the screen by percentages, or a StackPanel to stack controls so they as they fit. GridViews can scale to fill the screen (and beyond). This will let the app flow to use the available space.
MSDN discusses this technique in Quickstart: Defining layouts
For larger scale changes where the app should make bigger changes to adjust to larger changes such as portrait vs. landscape vs. snapped modes you can use Visual States. Visual States allow the app to set a specific state (e.g. "Landscape") which automatically changes properties of the page's controls. For dynamic layout the visual states will typically hide and show different controls, for example to switch from a horizontally oriented GridView in Landscape mode to a vertically oriented ListView in Portrait mode. By data-binding both controls to the same data the code-behind doesn't need to know any details about which controls are used at any specific time.
MSDN discusses this technique in Quickstart: Designing apps for different window sizes
Blend has a very good Visual States editor that you can use to define and set up different visual states visually.
The same techniques and code apply to Windows Store apps and for Windows Phone Store apps, but the exact layouts are likely to be different to cater to the different device sizes. Windows Store apps run on a wide range of display sizes and users can resize Windows Store apps freely, so Windows Store apps need to support much more flexible layouts than Windows Phone Store apps. Windows Phone Store apps need to take display resolution into account, but run on fairly consistent aspect ratios which change only for portrait or landscape.
For very simple apps you may be able get away with sharing a single Xaml page in the Shared project of a Universal app, but in most cases you'll be better off with separate page designs for Windows Store and Windows Phone apps. In addition to the screen size differences, there are a few control differences that will require separate Xaml. Xaml doesn't support conditional compilation, so a Shared Xaml file would need to be exactly the same in both.
For Windows Store you can use 'visual states'. You can set rules that determine which visual state is to be used, e.g. when the width is 320 switch to snap mode and modify the layout to suit.
Be careful when looking up information on this because the paradigm changed a lot between Windows 8 and 8.1.
Jerry Nixon has a great tutorial on visual states:
http://blog.jerrynixon.com/2013/11/windows-81-how-to-use-visual-states-in.html
This post from my blog covers a simple scenario using code behind only (VB, but should be easy to change to C#) - not advisable when you have a complex layout:
http://grogansoft.com/blog/?p=116
And there is a sample somewhere amongst these on the Windows Dev Center:
https://code.msdn.microsoft.com/windowsapps/Windows-8-Modern-Style-App-Samples/view/SamplePack#content
For the phone version(s) you should probably not bother with visual states as a phone app always has the full screen, and it's a better user experience to lock the display to either portrait or landscape.
Your phone/Store apps can share controls, but they have their own pages. I usually create full sized and smaller versions of any data-bound controls and use the smaller size on the phone and when the Store version is in a small state (e.g. 1/2 the screen).
I'm writing a tile editor for a game and would like to be able to select which level file to open. Once open I would load the level into an XNA window and click to add/remove tiles to the level. When the editing is finished I would save the file layout back to the original file.
Currently I don't see a way to integrate windows forms and XNA. Is this even possible?
When I was working on a small, "2.5D" isometric game in XNA, I found it worth while to also have a separate WinForms version that would just render a 2D top-down view using GDI. This was due to my inexperience with XNA and my (relative) comfort using WinForms.
This approach also had the useful side-effect of enforcing separation between logic and rendering code. It made it easier (for me, at least) to test changes without having to worry about how to deal with the XNA rendering aspects.
It may not be exactly what you had in mind, but it might be something to consider.
WinForms and Xna can cooperate, but it's not recommended to use Xna's built in Game class with WinFroms. There are two samples demonstrating it:
http://xbox.create.msdn.com/en-US/education/catalog/sample/winforms_series_1
http://xbox.create.msdn.com/en-US/education/catalog/sample/winforms_series_2
I have a C# Windows application (i.e. not a web app) in Visual Studio. The original development environment was a Dell Latitude D800 with a 1920x1200 pixel screen. Since the large number of pixels made the text very small, I adjusted lots of different default fonts in the name of readability.
I have moved development to new laptop, a Latitude D630 with 1440x900 display. The app was moved by creating a new project on the new machine, and adding the existing objects/files/etc.
THE PROBLEM is that many of my forms are no longer displaying uniformly. Some are now too large so that items on the right are out of the frame, and others are smaller with excess space on the right of the frame. It is as if the value of a 'pixel' is now different from one form to another. These changes persist when the executable is installed on production machines.
Any idea on what happened, and how to restore order? Thanks.
A good bet would be to check your font DPI setting. By default its set to 96. Its part of your windows display settings.
As best I understand, that would not explain why some forms are affected differently from others.
Winforms contains a lot of technology designed around the problem of making the display of forms reasonably resolution-independent. But a lot of this technology requires you to understand and use it - anchoring, docking, layout panels, and automatic scaling, for instance. If you've misapplied these properties, you often don't know about it until the day that you first test your app at a different resolution.
Unfortunately, there isn't really a magic bullet answer to the question "why are my forms screwed up?" Your forms are screwed up because resolution-independence wasn't designed into them. There's a whole host of possible problems: you could have controls anchored to the wrong things, someone could have "fixed" a layout problem by overriding automatic scaling on a control, really, it's endless.
Often, the best way to fix this kind of problem in a legacy app is to slowly build up a prototype duplicate of the offending form in a test application and watch its behavior when you resize it and change your screen resolution. That'll help you identify how the form should originally have been designed; you can then take what you've learned back to the original form and fix it.
And then design this into your development process from the beginning. One of the reasons that I don't have these problems in the big UI-intensive desktop app I'm building is that I've made every form in the program resizable, and I resize them during testing all the time to see if they're screwing up. I also test with different screen resolutions as a matter of course. These are the kinds of problems that are really hard to solve once they've become systemic; spotting them early keeps a lot of misery out of my life.
Some experimentation reveals that the declared size of a form apparently affects the size of objects in the scale (length and width units per screen inch) of the form when displayed as a maximized MDI child.
I have no idea why it should affect that.