We received a large net desktop application from another agency to implement at our agency. It's messy, but works. It uses a midi form with forms opening inside that, and panels. We compiled and deployed in Visual Studio 2015. It's VB.
All users have Windows 7 64 Pro. For one user, when forms open, the lower portion is cut off. If restored (un maximized), the form shrinks to a tiny window in the upper left of the midi window. If borders are dragged the form will expand, but only a small portion of the form at the upper left will contain anything, as if inside a shrunken panel with scroll bars.
I changed the application so forms have a minimum size that should prevent them from shrinking down, but that doesn't work on her machine. I also changed a couple of panels to "fill" similar to adjacent panels. On other machines the application works excellent, even if display is changed to larger 150%. On the problem machine, the application only works if the display is set to smaller 100% and will not work on medium or larger. The user chooses to have larger.
I can place code on resize events and try to force everything to display correctly, but should not have to do that. The application works correctly everywhere else. Something is different about the problem machine where window metrics are not being computed properly or something similar. All machines are made from the same image and have the same drivers. I cannot see any additional software installed.
I would like to know if anyone else has seen this issue and how it was resolved.
I have a windows form in my vb.net application which has recently started resizing itself dependant on the computers screen resolution.
I would like the form to be a fixed width and height - how can i make it do this and not resize itself?
You may try to change the property AutoScaleMode.
The default is FONT (the correct to most different systems DPI), but you may try other options there.
UPDATE
I saw now you may set the PROPERTIES of a file in the DESKTOP to "Deactivate Dimmension in High-DPI Settings" (it´s translated from Portuguese, my system). Click in the desktop application´s properties (its icon) and go to COMPATIBILITY TAB.
It´s not a .NET solution but if Windows had put it there, is because it´s possible the only way to set it.
I am new in VB application and can't figure out what's wrong with my app. There is a form which has a couple of labels and text fields. When I run the app on my and few other folks's machines it displays fine with proper alignment and font. However, for some people application form UI is broken unaligned text and buttons. Any one have any idea what's wrong with my application?
Okay, After some research, we found that the display settings for those users were set to 125% and because of that there were UI issues. I changed the display settings back to 100% and Booom it works just fine. Thank you all for you help.
This problem can occur for a number of reasons.
In my experience, however, it is commonly caused by setting the Font on controls, only to discover that certain users do not have that font installed on their machines. As a result, Windows forms selects a font for you that it believes is a close approximation--usually with horrifying results. Widths don't match, and controls end up horribly aligned.
Make sure you are not using a font that is not built into the OS. If you are designing the application in Windows 7, for example, and shipping to multiple platforms (Windows 2000, Windows XP (the horror!), and Windows 8), you may find that font availability is drastically different on these various platforms.
Though not aesthetically pleasing, stick with the lowest common denominator in these cases. If you can, use Segoe UI, which should be present on all these platforms (except XP) and which Microsoft now recommends.
I have an application written in vb.net which works fine in both Windows XP, Vista and 7. However, in Windows Vista and 7, the button layout (specifically the Exit/Cancel button at the bottom right) of all the forms acts weird, as the Exit/Cancel button runs all the way touching the edge/boundary of the form as shown in the pic below.
This does not happen in Windows XP. Nor does it happen on disabling the Visual Styles in Windows 7, as shown below
What can be the cause for this issue and is there any way to solve this, so that it looks good for both XP and Windows 7?
EDIT: I'm posting this on behalf of a friend - Abhijit (https://stackoverflow.com/users/2642426/abhijit-hota) - who wanted to post this himself but had less than 10 reputation. Apparantly you need to have at least 10 reputation to post a question with an image.
One way to fix it is the place the buttons in a TableLayoutPanel. Then you can
Move it a bit further from the edge
Or leave an extra column on the right as a margin or gutter
Or anchor it in a way (left maybe) to prevent it
Another possible cause is that the controls are not using the Anchor property and he has tried to neatly line them up with something as an absolute position (which Visual Stlyes messes up as relative sizes and text extent changes). Any given user may or may not be using Styles Anchors so a layout panel works well to neaten things up.
I have a virtual machine (VMware) with Mercury Quick Test Professional 9.2 installed. I have a script to test an application, written in VB.NET using the Infragistics library.
If I access this virtual machine using my laptop (using Remote Desktop), everything works fine, the script completes without a problem. My laptop runs XP, with Windows Classic theme.
If I access this virtual machine using another machine (using Remote Desktop), the script starts fine, but stops halfway through, without no error message from QTP, nothing. This machine runs XP, with Windows Classic theme.
One difference between the two setups is the size of the screen, the laptop is 1920x1280, other machine 1280x1024.
The step where the script stops involves checking a checkbox within an UltraWinGrid. The checkbox itself is displayed, is on the screen in both cases.
Has anyone had this problem before, or have any idea why the behaviour is different between the two machines?
Thanks.
OK. I've found the problem. In fact, the script was failing silently because that's what the person who wrote the script told it to do. It couldn't validate something which was off screen, so the script failed.
The problem was the QTP definition of 'off screen'. I have two screens attached to my laptop, the screen for the laptop itself (1920x1200) and another screen (1280x1024). I connect to the VM for QTP using remote desktop, and it uses the settings of the screen for the laptop. This means that when I launch my QTP script, and move it to the other screen, it doesn't fit, so the screen is no longer maximized, and the object is partially off screen, so can't be found.
The fix is simple: in the Remote Desktop, use the Display tab, and set the size of the screen to a size to 1280x1024, and QTP doesn't have any more problems.
Voilà.
If you are not using Expert Mode, and / or are allowing QTP to do most of the work to create your repository objects, then yes it is referencing everything by pixels.
I create all of my repository objects by hand, viewing the source (in the case of automated web-application testing) and using the Object Spy for assistance where needed. I make a point to not have any positioning information as part of my object definition, for the very reason you are running in to.
For the parts of my web-app that interacted with Windows (opening a file to upload, etc.) the Object Spy was essential for the trial and error necessary to create a unique identifier for creating the repository object. But it can be done.
Ex1: File Browse Dialog
text = "Choose file"
nativeclass = #32770 (apparently some Windows VooDoo for a file open dialog?)
Ex2: Filename textbox in Browse dialog:
nativeclass = "Edit"
attached text "File &name:" (more Windows VooDoo? It woudn't work for me without the "&")
Ex3: Open Button in the dialog:
text = "&Open"
object class = "Button"
Good Luck!
Point of clarification: You mentioned that QTP stops with no error message. Does that also mean that the test results log file also has no error message? If the log has any information, that may be helpful in diagnosing the problem. Could you share the lines of code at the point where the script fails?
Also, remote desktop will resize the desktop on the remote machine. Although QTP scripts are not inherently coordinate based, individual statements can be coordinate-based relative to an object. The resolution could be an issue in that regard. For example, imagine you had a line like Button.Click(5, 150) recorded on a higher resolution machine. But if you attempted to play it back on a lower resolution machine, and the 150 is out of bounds of the object on the lower resolution, it could cause an issue.
QTP does not use screen coordinates except as a last resort, if the objects are identified as high level objects (SwfTable in this case) you should be OK, if however QTP doesn't recognise the object it falls back to WinObject and screen coordinates.
If you're using Infragistics then you should know that they extend QTP's support with their TestAdvantage product which will probably solve your issue.
Edit:
#MatthieuF said:
In fact, we use the Infragistics plugin for QTP, and we still have the problem
Can you give me an example of a line that fails?
A few things:
You should be able to debug on the VM easily - just wait for it to stop, go into your object repository, and see if it can identify the object. If no then use object spy to figure out what properties are different between the OSes. If there is a difference then you can always set that property to a regular expression and have it check for both possibilities.
Assuming that isn't the issue we've run into problems using remote desktop with QTP if the Remote window is closed or minimized. For us, it was an issue where the clipboard can not be changed when an RDP window isn't visible, but there could be other surprises when using QTP that way.