How can I resize my vb6 program so that it automatically fits in any screen resolution? - vb6

How can I have a vb6 program which opens correctly in 1280*1024 but when switched to other resolutions say 640*480 i can only see half of the screen. how to re-size my vb6 program so that it automatically fits in any screen resolution?

You need to use the Screen object, this will always give you the current resolution in pixels:
Dim screenwidth,screenheight As Single
screenwidth = Screen.Width \ Screen.TwipsPerPixelX
screenheight = Screen.Height \ Screen.TwipsPerPixelY

Usually a Form amenable to resizing has controls that lend themselves to a "flow" layout. Often this is something like a TextBox, grid control, etc. that supports scrollbars. You shrink/grow such controls as required after allocating positions for (i.e. moving) the fixed-size elements like buttons and such.
For a busy Form with lots of fixed size controls that isn't "document oriented" there is no set answer. Sometimes creating a scrollable Form makes sense but usually it doesn't.
Some people try to resize "fixed" elements, change fonts sizes, etc. This can produce results of mixed quality though, sometimes good and sometimes not.
Considerations about the Form size are best made up front as part of the design process. For some applications it might be better to decide on a minimum supported Form size. In other cases you may have to break things up with dialog Forms or tab controls.

There's no easy way to do this in VB6, like there is in .Net. You have to manually resize everything in the form's Resized event handler based on the new form's client size. It's a pain, and a huge mess, but it's the only way to do it.
Correction: There's never only one way to do things, but I've been programming VB6 for several years, and usually just writing it into the Resize handler is straightforward enough, and I haven't found any good way to do it other than that.

Have you tried any 3rd party tools for doing this? Here's (a free) one that seems to work :-
ActiveResize Control Lite - I created a quick project to try it and it does what it says on the tin!
The lite version has some limitions such as number of forms in project, number of controls on form etc. You can also buy a Standard or Professional version if you need more functionality.
I know we've spent countless hours trying to implement our own resizing code only to remove it all and fix the location of most controls, move a few to make it look better and limit the min/max functionality of the form - none of which give a nice user experience. If we needed to do it again I probably use this control (or a similar one) just for the time savings.

I use ComponentOne SizerOne
The C1Elastic control allow from resizing and maintain the aspect ratio, resizing the inside controls on the setting you defined.
It's not free, but it payed itself with all the time I saved.

Form1.Height = Screen.Height
Form1.Width = Screen.Width
This code sets form size according to screen resolution.

"ActiveResize Control Lite" ActiveX tool is limited to 20 controls per form.

Once we know the screen resolution, there are a number of things you can do.
• The easiest solution would be do design different form to accommodate the four most popular monitor resolutions – 640 x 480, 800 x 600, 1024 x 768, and 1600 x 1200.
• Alternatively, we could write code that dynamically resizes and relocates every control on the form, based on the screen resolution – not an easy undertaking!
• Third party controls that resize the controls based on the screen resolution are quite effective. On the whole, though, it's better to just avoid this kind of problem, if you can. For example, see Creating Flexible Forms in Visual Basic (Flexi-Forms) at codeguru.com

To auto fit screen resolution you need to download an active x, drag it on your conform.
Search for "veg gold vb6.0 screen Resize".

Related

WP7: IsolatedStorage vs. WriteableBitmap

I have a scenario that I need some good solid advice on. The question is really about speed of WriteableBitmap vs. images in IsolatedStorage on the Windows Phone.
I have an app that displays a UserControl (#1) which is a little graphically heavy. When the user swipes it, it transitions in a push-left type of transition to bring in a new UserControl (#2) which is also a little graphically heavy. If the user swipes the other way, control #1 is brought in in the same type of push-transition, this time from the right.
What I do today is take a snapshot of #1, load #2 off screen and take a snapshot of it, put both side-by-side in a Canvas control and animate that control either left or right. One of the reasons I don't just use the controls and animate them is they may have animation that starts when they are loaded - my current technique allows me to capture a screen shot of pre-animation and post-animation, depending on which direction they go in.
What I'm wondering, however, if it would be better/faster to just do the above the first time and send the writeablebitmap to IsolatedStorage with Extenstions.SaveJPEG and just use that instead in subsequent tranistion animations.
Would load/render/WriteableBitmap each time generally be faster or load jpeg from IsolatedStorage be faster each time? I see that the Transitions control in the SDK doesn't really do either of these, so I'm open to suggestions that are different that also might improve performance.
I expect this to be very depended on the hardware and application. So it is pretty hard to give an answer based on this input. It doesn't look to hard to test (on actual hardware and with the actual application) so my advice is to build both and test.
The applications I have been working with use both approaches and to be honest I haven't noticed much difference.
Also you might try and enable bitmap caching on the controls. This will give you a writeable bitmap implementation that is very fast.

Calculate actual size needed for a MATLAB uicontrol

I'm trying to calculate the actual size needed for uicontrols in a GUI so the GUI can resize itself appropriately. My problem is that the Extent property of a uicontrol is only the text area, and I can't find a way to determine the size of the surrounding control (such as the down arrow in a popup or the margin of an edit control). Is there a way to get the size of the decorations on a control?
I saw this related question on MATLAB Answers, which looked like it ended with no solution as well.
Edit:
For example, I want to calculate how big this popup should be to avoid cutting off the contents:
uicontrol('style', 'popup', 'string', {'a long string'})
Extent only tells me how big "a long string" is, and I still don't know how big to make the popup. I want a way to determine how much extra space is needed on the user's display (without assuming which OS or font sizes they use).
You can use get(hObject,'extent') to find out how much space the string contained in the uicontrol takes up. You can see if this is larger than the uicontrol's position.
The uicontrol Position property gives you the height and width of the bounding rectangle for the control. This has always worked for me. Is there a control where this property does not provide enough information?
If the GUI you're building can be assembled exclusively from Java components, you can use MATLAB's Java integration to create and drive a window using Java Swing components (all from M-code). That sidesteps the problem entirely, since the Java layout managers can do UI layout properly.

Cocoa Scalable Interface for Digital Signage Display

I'm working on a Cocoa application which will be used for a digital-signage/kiosk style display. I've never done anything like this with Cocoa before, but I'm trying to figure out what the best approach is for building the user interface for it.
My main issue is that I need a way to have the user interface scaled up or down depending on the resolution of the display. When I say scaled, I mean that I want everything including white space to maintain the same sizing ratio. The aspect ratio of the interface needs to remain the same (16x9), but it should always fill the entire width of the display its on.
Sorry if I'm not being descriptive enough.
What are some thoughts?
If I follow you correctly, you want all buttons and views, etc. to get larger, the bigger the screen is (which has nothing to do with the dimensions of your views). If that's the case, there's no automatic way to do this.
With Quartz Debugger (part of Xcode Tools), you can set the scaling factor (see "resolution independence"), but this would need to be manually adjusted per system. What's more is I'm not sure if this tinge is persistent across reboots. I leave that for you to investigate.
As far as I know, though, there's no way to adjust this programmatically as resolution independence is still not an exposed consumer feature of OS X.
If anyone is interested, I seem to have found a solution under this post: http://cocoawithlove.com/2009/02/asteroids-style-game-in-coreanimation.html

Any suggestions for best practices to follow when creating UI prototypes using sketchFlow for multiple screen sizes?

am looking to prototype the UI for an windows application. The app will be deployed on several display devices with different (physical) screen sizes and aspect ratios. Would like to be able to generate scenarios optimized on one display and quickly check if the layout is OK on different screen sizes, orientations. That is, I'd like to prototype one set of scenarios and "automatically" generate the same scenarios on different screens. Have superficial knowledge of MS Sketchflow. Have seen some best practices at http://www.wpftutorial.net/LayoutProperties.html#best . Am wondering if folk can advise on best practices to follow in sketchflow.
Bye
To quickly be able to check how things will look, I have 2 possible suggestions:
Use the states panel to create a state group/states that change the size of the layout container (such as layoutroot) you are working with. Then in the sketchflow player, you can select the state from the navigation menu and see how it looks.
Use a ChangePropertyAction behavior from the asset panel attached to a button. You can set the height or width to the size you want. If you use 2, you can set both the height and width. This would give you the ability to control the layout size and see how it is rendered.
Hope that helps, let me know if you need more info.
Keep a consistent theme between the pages, kind of goes without saying.

What screen resolution should my web app target for an average non-technical users?

I noticed StackOverflow appears to be targeting screen resolution widths of 1024px or more. I also checked Amazon, NBC, MSN, & AOL which target more lay users, and they all appear to be targeting the same width.
Is 1024px the current recommended width for web apps targeting the largest cross-section of users who use default monitor resolution/browser size?
Use liquid layout. Then you can easily accommodate everyone from ~800 to ~1600 width, and with a bit more work and care even lower-resolution devices too. This also gives users #1024 some leeway to zoom the page if they find the text too small.
Remember there'll be things like netbooks which don't have the big screens we expect today. You can get away with a horizontal scrollbar, but if you have to scroll the page just to get the main body of text in, you're lost.
Before sounding so condescending, you may want to read up on the modern user base. Netbooks. PDAs. Smartphones. Smartbooks (you do know what those are, being very sophisticated, right?). Programmers who have their screen in portrait orientaton. People who stack their windows side by side. Kiosks.
UPDATE As per conversation with John, I edited the question to change the tenor a bit to reflect his original intent. However, the original paragraph that I wrote is still true- I haven't seen the latest statistics but the days of "90% of users have AxB resultion/window size on their browser" are probably forever gone, what with wide screen laptops and mobile devices. Makes life more exciting for UI designers :)
Having said that, to develop a really usable web site, you need to couple flowing layout with, ideally, ability to use portlets and portal framework (think My Yahoo), so people can choose the page layout most comfortable for them.
make a good use of 960.gs and you will set everything that you need to start a good web site :)
(source: balexandre.com)
The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are two variants: 12 and 16 columns, which can be used separately or in tandem.
960 GS it's a lovely start, doing web or images, they have a complete template for almost any good design program (Photoshop, Ilustrator, Fireworks, InDesign, etc) as well a CSS generator and a Grid Overlay to help you with the website.
I use it and it's fantastic! check out the demo
Nettuts has a tutorial and video. WooThemes wrote a post entitled “Why we love 960.gs” and use it as a starting point for their WordPress themes. Spanish speakers can also check out tutorials by Jepser Bernardino and Miguel Angel Alvarez.
Unsophisticated? I think that's a bit of a rude way to describe the unwashed masses. I suppose every one and their dog has a 1024px width monitor now thanks to the likes of dell and others...
The maximum I would consider targeting as my "base" is 1280x1024, but I would be much more likely to go 1024x768.
That said, in my current projects I try to do a liquid layout with a min-width of 800 to accomidate netbooks and usually a max-width of around 1000px (970 usually). Of course, I also have the luxury of designing for myself, so I have the privilege of telling IE6 users that they should upgrade, which makes the liquid layouts much easier to design.
Summary:
Design with your browser's inner dimensions set to 1250x668 to satisfy 92.7% of users.
I like being stats-driven. To this end, W3Schools has a nice Browser Display Statistics page, which they update periodically with new statistics on how common each screen resolution is.
As of January 2015, 92.7% of browsers visiting W3Schools pages were attached to displays larger than 1024x768, though 39.3% of all displays were limited to 768 pixels in height (or lower), mostly due to the 33% of them having 1366x768 displays.
Unfortunately, W3Schools measured screen resolution rather than the inner dimensions used for rendering web page content. It'd be real nice to get stats on users' window.innerWidth and window.innerHeight instead.
Because we don't have these, we have to reserve room for window decorations that may be larger than our own, as well as browser widgets that may further take away from the space dedicated to rendering a web site. Additionally, not all users browse the web in a maximized web browser, though I think we can ignore that if we assume lower-resolution displays will have maximized browsers.
Windows 7 seems the biggest offender at eating up screen real estate, with what I'm measuring as 30-40px for the task bar (I had to search for a screen shot, as I don't run Windows). Firefox with titlebar, menubar, bookmarks toolbar, and status bar eats another 159px while the slimmer modern FF only consumes 64px. Let's use the slim version and assume around 100px of vertical space will be lost. Maximized browsers don't appear to consume any extra horizontal space, so you really only need to account for the scroll bar, but I'd reserve a few pixels for window edges just in case, bringing us up to 30px.
A few years ago (when I did more web design than I do today), I'd size my own browser to an inner size of 800x550 and made sure that most pages would not have scroll bars. Nowadays, it looks like that can be expanded to around an inner size of 1250x668.
You can check your inner size by putting this in your location bar:
javascript:alert(window.innerWidth + "x" + window.innerHeight)
Those values are read-only; you used to be able to run something like this to resize your inner dimensions, but (thanks to abusive advertisers) it no longer works:
javascript:window.resizeTo(window.outerWidth-window.innerWidth+1250,window.outerHeight-window.innerHeight+668)
One parting note: Just because you're assuming a certain size doesn't mean you shouldn't ensure that your site still works at smaller resolutions. The page can be ugly, but it must be functional!

Resources