For example, Windows Forms Designer offers to place my controls on the form the way there are 12 pixels between form border and control border. It seems too much to me. Is it standard value? Also, as I understand standard button height should be 23 pixels. Am I right? Is there any documents that state all this? And can I setup this default values in Visual Studio (for example what if want default margin between control and form borders, when the snap appears, to be 6 pixels instead of 12)?
You can always refer to the Windows User Experience Guidelines. It comes with a handy table of recommended control sizes. There are drawbacks in using pixel sizes, however.
I don't know of a way to control the snapping behaviour in Visual Studio, though. Apparently it can't be done. You can set a grid size, but it won't affect the dynamic snapping lines.
To change the snapping options, go to Tools > Options > Windows Forms Designer. There is a 'Layout Settings' category that include a setting called 'GridSize'.
As far as standards are concerned, I see them fading away with the arrival of technologies that focus on the user experience (WPF/Silverlight). Look at Expression Blend for instance. Not very standard, right? I think delivering a great user experience in each app is much more important than having a common GUI style across all apps.
Related
I've got the task to program a graphical network editor application as a university project. For that I need three types of items/controls. A circle shape, a rectangular shape and arrows to connect the other shapes (the whole thing works somewhat like MS Visio in some ways). The shapes/controls need some additional features like moving, scaling a context menu etc. Also I need to have full control over the graphical representation of these objects i.e. I want to 'draw' them myself or at least be able to modify them as I need.
I am using JavaFX and have little to no experience with it. So I was wondering, what would be the best way to implement these custom controls. It is required to use JDK 7, so using SkinBase and BehaviourBase is not an option, since they are private before JDK 8.
I was thinking about subclassing Path or Canvas to use as my controls. But I know too little about the implications to make an informed decision.
Could someone give me some advice, which base classes to consider and what implications that might have?
Thx alot.
This answer is just going to be advice, there is no real right or wrong answer here. Advice is necessarily opinionated and not applicable to all situations, if you don't agree with it, or it doesn't apply to your situation, just ignore it.
Sorry for the length, but the question is open-ended and the potential answer is complicated.
I was thinking about subclassing Path or Canvas to use as my controls.
Don't. Favor composition over inheritance. Have a control class which implements the functional interface of the control and works regardless of whatever UI technology is behind it. Provide the control class a reference to a skin class which is the UI representation of the control. The skin will specify how to render the control in a given state (getting the control state from the associated control object). Also, the skin will be the thing which responds to user manipulations, such as a mouse presses and instructs the control to change its state based upon the mouse press - so the skin knows what control it is associated with and vice versa. In the control class have bindable properties to represent the control state.
A simple example of this is the Square and SquareSkin from this tic-tac-toe game implementation.
For example, imagine a checkbox control. The bindable property of control might be an enum with states of (checked, unchecked, undetermined). A skin might render the checkbox as a square box with a tick mark to represent the checked state. Or maybe the skin will render a rounded edge with an X. The skin could use whatever technology you want to render the checkbox, e.g. a canvas or a collection of nodes. The skin registers listeners for mouse clicks, key presses, etc. and tells the checkbox control to set its check state. It also has a listener on the check state and will choose whether to render the check tick based on that state.
The key thing is that the API interface to the checkbox is just a checkbox control class with a check state. The way the UI is handled is abstracted away from the checkbox API, so you can swap the UI implementation in and out however you want without changing any other code.
Subclassing Path is quite different from subclassing Canvas. For the situation subscribe, I would definitely favor subclassing a Shape node (or Region) as opposed to a Canvas. Using Nodes, you automatically have a really rich UI rendering and event model, bindable property set and and painting framework which you won't get with a Canvas. If you don't use Nodes, you will likely end up trying to re-create and build some parts of the Node functionality in some sub-standard way. Canvas is great for things like porting 2D games or graphing engines from other frameworks or building things that are pixel manipulators like a particle system, but otherwise avoid it.
Consider using a Layout Pane for your control skin, e.g. a StackPane or something like that. The layout panes are containers, so you can place stuff inside them and use aggregation and composition to build up more complex controls. Layout panes can also help with laying out your nodes.
Anything which subclasses a region like a Pane can be styled via CSS into arbitrary shapes and colors. This is actually how the in-built checkbox (and other controls) in JavaFX work. The checkbox is a stack of two regions, one the box and the other the check. Both are styled in CSS - search for .check-box in the modena.css stylesheet for JavaFX. Note how -fx-shape is used to get the tick shape by specifying an svg path (which you can create in an svg editor such as inkscape). Also note how background layering is used to get things like focus rings. The advantage of using CSS for style is that you can stylistically change your controls without touching your Java code.
so using SkinBase and BehaviourBase is not an option
Even though you have decided to not use these base classes (which I think is an OK decision even if you are targeting only Java 8+), I think it is worthwhile studying the design of the controls in JavaFX source. Study button or checkbox, so you can see how the experts do these kind of things. Also note that such implementations may be overkill for your application because you aren't building a reusable control library. You just need something which will work well and simply within the confines of your application (this is the reason I don't necessarily recommend extending SkinBase for all applications).
As a minimum read up on Controls on the open-jfx wiki.
It is required to use JDK 7
IMO, there is not much point in developing a new JavaFX application to target Java 7. There were many bug fixes for Java 8, plus new and useful features added. In general, Java 7 is a sub-optimal target platform for JavaFX applications. If you package your application as a self-contained application, then you can ship whatever Java platform you want with your application, so the target platform doesn't matter.
IMO deployment technologies such as WebStart or browser embedded applications (applets), which can make use of pre-installed java runtimes on a system, are legacy deployment modes which are best avoided for most applications.
Still, there might be a situation where you absolutely must have Java 7 due to some constraints outside your control, so I guess just evaluate carefully against your situation. If you have such constraints and must build on a stable, legacy UI toolkit which works with runtimes released years ago, you could always use Swing.
From oracle, the Path class represents a simple shape and provides facilities required for basic construction and management of a geometric path while Canvas is an image that can be drawn on using a set of graphics commands provided by a GraphicsContext.
Which means the user can use canvas to draw the required shapes as the user wants.
On of the basic ways I can say would be as follows:
Use canvas as it will help and allow for custom user "drawing". Creating menu buttons for the circles, rectangles, arrows etc. like in MS Paint. Onclick drag function on the canvas can be used for "drawing".
Circle and Rectangle are available in the libraries which you can use
You can use arrows like the way used here.
I think its the same example as you want to create.
Custom controllers and context menus can be created too docs.oracle.com
Scaling and Moving can be done by binding drag function to a scale
or translate animation. Mousepressed and Mousereleased can be used to track the coords to draw the shape in.
This is my advice, you can use the control prototype.Or an application or design tool which can provide you the targeted control or a icon with circle shape, a rectangular shape and arrows. I don't know how my advice work. You can try it.
I made a flyout window in the notification area using WinAPI and my goal was to make it similar to the flyout windows that show up when you click some of the icons in the notification area, like the Volume icon.
I already succeeded in making it look and behave similar to the other ones, but there is one thing I can't seem to figure out. The link area of the flyout windows has a darker blueish background and there is a subtle difference in the look between Windows 7 and Windows 8. A picture of it in Windows 7 can be seen here
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511448.aspx#flyouts
I achieved this by painting this link area of my flyout window manually in the right colors (including the gradient at the topmost part of the section) using the WM_PAINT message, but I just feel like it's too much of a hack, especially because it's not affected by changing themes in Windows. For example, if I set the "Windows Classic" theme this area should be grey and not blue.
So, my question is, am I missing something in how this can be achieved without painting the window manually. I noticed that the details pane in Explorer windows in Win 7 has the same look. I've searched quite a bit for answers but I haven't found anything yet. This is my first time doing a GUI using the WinAPI so I have very little experience, and therefore I'm assuming there is something that I just don't know about.
UPDATE:
I did manage to figure out how to draw this area without painting it manually. It can be drawn by using the OpenThemeData and DrawThemeBackground functions
HTHEME aeroTheme = OpenThemeData(hWnd, L"FLYOUT");
DrawThemeBackground(aeroTheme, hdc, FLYOUT_LINKAREA, 0, &rect, &rect);
This obviously only works when themes are enabled, so for non-themed cases I draw a normal rectangle with the appropriate color.
I'm not an expert in WinAPI so I can't offer any advice on achieving the look you want without manual painting.
However, if you're successfully achieving the appearance for a particular color theme, I'd suggest you look at the GetSysColor function and use this when creating your brushes for painting. This should allow you to get the correct colors based on the theme that has been set. More info (including a swatch table) can be found here.
Hope this helps.
I am working on a data entry application and I am considering using a fluid layout approach ala Swing and Silverlight where the controls resize based on the window size. My question is simple: what feedback if any have you received from users on each of these approaches? Screen size aside, I will still have a vertical scroll in place so I am wondering if I would be best served to simply go the fixed route and absolute position/size content.
Do not go the fixed route. If the user resizes the window, they do so for a reason. The widgets should resize appropriately. I can think of no valid reason to ever use a fixed layout except in vey specialized circumstances.
That being said, don't have a layout where input fields wrap. That would be very disconcerting. Just let your widgets grow and shrink naturally.
I have applied a color theme called Vibrant Ink (or some modification of it), and since I installed Visual Studio 2010 Pro Power Tools all my statement completion boxes are unreadable.
undreadable http://img139.imageshack.us/img139/7876/undreadable.png.
What setting changes the colors of these boxes? Preferrably, I'd like to change the background color to something darker, but if that's not possible at least I want to change the text color.
Update: I changed the SignatureHelpTooltipBackground setting under Tools->Options...->Environment->Fonts and colors, but this doesn't seem to affect the tooltips when editing JavaScript.
Is there another setting for JS colors, or is this a bug in VS?
The "default" ToolTip style has hard-coded colors that will only be different if you are running in high-contrast mode. Otherwise, it will be the light gray gradient you see in the picture above.
The tooltips in the ProPack for VB/C# files use a custom (configurable) style as you noted above.
Please submit feedback that the default tooltip background color should be configurable. The more customer requests are heard for this issue, the higher the likelihood it will be fixed in a future release:
http://connect.microsoft.com/VisualStudio
I'm not sure it is legal or not, we can always disassemble the code and modify (patch) what we want. In this case, find that gray color in assembly and change it. It shouldn't be hard for someone who knows .NET and hexes well.
I'm using the ssOption control (Sheridan 3d Option control) in VB6.
In Windows 98 the text area background color is the same color as the background color around the Option Circle, and that color is the default form color. So the Option button appears to be transparent.
There is no Background color property and on Windows XP the background color of the text area is a different color from the background color around the Option circle.
Any ideas as to why this would happen? The control's wrapper is in Threed32.ocx and I have the same version of it in the Windows\system32 directory on both the Win98 and WinXP systems.
Why might it behave differently on 98 vs XP?
Any ideas on a fix?
SSOption sets it background to the Windows Button Face on Windows XP. This the same background you get when you make a new form. You will need to use a frame or another type of enclosure that has a background of button face if you want to use it on a multi-colored form. Otherwise use VB6's Option button.
The advantages of the SSOption is the ability to display it's text in a 3D raised or inset format. This really only works well using the default button face color which is why it is hard coded into the control. It also has better formatting of the text when the option button is to the right of the text.
If you can't use a enclosing frame or panel then you have a tedious alternative. You can make an VB6 option with no text. If you are using the 3D font. Then you can use two labels to achieve the same effect. Make the bottom white (or top depending on raised vs inset) and offset by one pixel or 15 twips.
You can use the ZoomIn tool if you installed VB6 as part of the Visual Studio 6 package to make sure it is right.
If you are using it for the Alignment. Then you can fiddle with the width of the VB6 native option control until it looks right or make the option with no text and use a label.
Threed32.ocx is ancient - it was designed for VB4. I would replace it with the built-in VB6 option control.
Alex is right. Threed32.ocx is old and has a number of problems. It's not supported on Vista, it grabs the focus when it's made visible, it's hard to upgrade to VB.NET - there are more. For my company these are strong enough to outweigh the extra functionality it gives - we're droppping it from all our programs.