I have a laptop that has both HDMI and VGA connectors; my TV is connected to the HDMI port (set at a resolution of 1600x900), and my desk monitor is connected to VGA (at an old-fashioned 1280x1024). The GPU does not allow for both external ports to be used simultaneously, so I end up having to switch between the one and the other, depending on whether I want to watch my shows and movies or sit behind the computer.
So far, so good... but (me being OCD about that stuff) I want to have a different wallpaper depending on the active config (laptop + TV or laptop + VGA), set by some script...
To catch the change between setups (Intel Graphics, using one of two preset profiles) I need something that monitors the active monitors for changes.
I've found a simple solution using SystemEvents.DisplaySettingsChanged, but this only works when I run the code from the VB.Net IDE. As soon as I compile and run the exe, the event doesn't seem to get triggered anymore.
I also tried a continuous loop using the Windows.Forms.Screen.AllScreen array, but the same applies: runs like a charm from within the IDE, but when compiled, it never detects the change.
Skeleton code for the first option (run as a console app):
Imports Microsoft.Win32
Imports System.Threading
Module Module1
Public Sub MyEH2(ByVal sender As Object, ByVal e As EventArgs)
Console.WriteLine("Display has changed")
' Actual code do change wallpaper comes here, natch
End Sub
Sub Main()
AddHandler SystemEvents.DisplaySettingsChanged, AddressOf MyEH2
While 1
Thread.Sleep(1000)
End While
End Sub
End Module
My question is: why does this work when started within the IDE, but not when compiled as an EXE? (In other words: why doesn't the compiled version detect the changes?)
I'm running Windows 7 Home Premium and using VB.Net 2012 (Express)
I want to say thanks to those who came up with suggestions, but I went the lazy way... I downloaded and installed AutoIt, and managed to make a reliably working exe with it in less than 10 minutes... still using a continuous loop to check for a change in display resolution, then--when it does--run a vbscript I'd already verified to work to update the wallpaper file and force refresh the desktop.
it almost looks like it's a feature-not-a-bug thing, this seemingly simple WMI query not working from a VB .Net Express executable.
Related
I have an application in vb.net that I'm testing out in Windows 10 and I seem to be getting an error (Images below). This app works flawlessly in Windows 7, and it actually works without any issues in Windows 10, the problem is, when I exit the application is when I get the error.
The way it's structured, is if I run it from IDE, i first see a Login Windows where user logs in and then goes to MENU. If it's run in our environment, user does not have to log in, so the log in form never appears, it goes directly to MENU.
Everything works great, until I go to EXIT Application, where it gets all messy, this is the code from EXIT button...
Dim Answer as Integer
Answer = MsgBox("Are you sure you wish to Close the application ?", MsgBoxStyle.YesNo)
If answer = vbYes Then
End
End If
These are the errors I get:
First I get this error, clicking on CLOSE PROGRAM closes it completely, if I click debug I get the below windows....
With the 2nd error it shows that I actually have VS2010 and VS2012, and it lets me debug. The issue is, the source code is in TFS, and it just so happens that I can't access the TFS from my windows 10 machine, (only from Win 7). So I can't debug it. But is there a reason why this is happening only in windows 10?
I even went as far as doing Me.Close() before END to make srue that the form is closed. And again, it works fine in Win 7, but win 10 it gives me the same problems.
Using "End" to close a program can be problematic; the comments and answer to this SO question explain why that is. As for the second issue that popped up once using Application.Exit(), that is a simple case of your program referencing multiple assemblies that have function calls with the same name. In this case, both the explicitly imported Microsoft.Office.Interop.Excel and implicitly imported System.Windows.Forms have "Application.Exit()" members. Since you have explicitly imported Excel, the compiler goes with that one when it's forced to decide which Exit() to use, which throws an error because of the context it's being used and doesn't actually close the program. To rectify that, all you have to do is explicitly tell the compiler which Exit() you want to use by replacing
Application.Exit()
with
System.Windows.Forms.Application.Exit()
I'm look for code which can help me accomplish what the title suggests.
I want this because I have an issue with a program which is quite buggy (it's a game), and if It freezes, and results in a black screen. Even after using Shift+Ctrl+Esc, Ctrl+Alt+Del, Alt+F4 and the rest of them, I acn't seem to end the program. So I thought that a KeyPress event would work, as it doesn't require me to use the UI in any way.
However, I've never used VB for anything other than Form's, so I have no idea how to start on something which runs in the background.
Thanks :)
A background app won't help in this case.
Ctrl+Alt+Del is specail key combo that is handled directly by Windows and can't be intercepted by a running program.
What this means is that if your game locks up and Ctrl+Alt+Del doesn't bring up the Windows menu, then the game has corrupted the system. The only fix at that point would be a restart.
That being said, you can kill a running process using VB.NET like this:
For Each program As Process In System.Diagnostics.Process.GetProcesses
If program.ProcessName = "ProcessName" Then
program.Kill()
End If
Next
Read more about it on the MSDN.
Okay, so Windows isn't actually locking up, but you just need some way to kill the process. Use the above code, replacing "ProcessName" with the name of your game process, and then either:
(basic) Turn the VB.NET code into an .exe file. Then set up a keyboard macro (using your keyboard software or some freeware) to launch the .exe you made which will kill all running instances of the given process. or...
(advanced) Import "user32.dll" into the VB.NET code, call SetWindowsHookEx with a hook id of 13, a pointer to a LowLevelKeyboardProc function, the handle to your running program, and a thread id of 0. Then, whenever a key is pressed in any program, your KeyboardProc function will be invoked. If the key(s) pressed match your desired kill-key combo, then run the above process killing code. This looks like it may give you more step-by-step instructions.
I use this code :
Shared Sub OpenApplication(ByVal ApplicationPath As String)
Dim p As Process
Dim ShowForm As New Form
Dim FormPanel As New Panel
FormPanel.Dock = DockStyle.Fill
ShowForm.Controls.Add(FormPanel)
p = Process.Start(ApplicationPath)
Threading.Thread.Sleep(500)
SetParent(p.MainWindowHandle, FormPanel.Handle)
ShowForm.Show()
End Sub
but it run the application inside the panel with the border.
if i make my own virtual operating system, how do i change the border to none?
like windows 7 have their own form border, windows 8 and mac too.
but I make my own form border. it's graphic, how can I make the application use my border?
this is some example(i cannot post image) :
Windows 8 Notepad with Their UI Design (it's Form Border for me)
Windows 7 Notepad with Their UI Design
And this is my UI Design :
(sorry I cannot insert more that 2 links, delete space in http:"Space"//)
http: //40-89-67-30-21.weebly.com//files/theme/Notepad.png
how can I Make like this when double click notepad.exe or another .exe file in my virtual os? (this is edited version !) :
http: //40-89-67-30-21.weebly.com//files/theme/Notepad_edited.png
it's run the exe but with my own UI Design. How can I do like that?
By default 3rd party applications don't support their re-branding by 4th party developers and even OS-specific coding conventions don't force them to do so, except for support for branding the OS, like respecting system colors, accessibility features etc.
In order to implement this you'd have to do a lots of low-level hacking, intercept UI messages (like WM_NCCALCSIZE or WM_PAINT) etc. or replace complete libraries containing the UI drawing API (like GDI32.DLL) with your own.
All of this requires precise work, good understanding of the various low-level aspects and code well-coordinated with the rest of the system and approximately few thousands of lines of code, including some native (not managed) code.
It's doable, but not simple, see e.g. Stardock's WindowBlinds
See also:
Google search windows skins
My application was built with VB.NET. It's an EXE application.
It's already running well on dozens of Windows hosts as an independent app - without a development environment.
Now I try to run it on a Windows 2008 server (as a native app), but the form is not shown - nothing is displayed. When I debug, I see that it's running all "form_load" subroutines until the end, but then nothing is displayed. I find no errors.
What could be the reason? What should I check?
I must say that it works fine on many other Windows machines, but not on Windows 2008 server machines (we tried on another one).
It's not a database application. GUI only.
Thanks in advance!
You say "nothing is displayed." But does the application show up on the Windows Task Bar?
It's possible that the form IS displaying - but that the position is off-screen. For instance, the upper-left-hand corner might be at (1300,1100) or at (-1300,-1100).
Try running it again, but then (when the form OUGHT to be visible) try pressing ALT + SPACE. If your window really does exist, you'll see a system menu (Restore, Move, Size, etc.). In that case, select Size - you ought to be able to use the mouse and/or keyboard arrow keys, to make the window visible.
On the other hand, if the application is supposed to show up in the Windows Task Bar, but it doesn't, then something is happening in (or right after) form_Load that is making the application exit. To double-check if this is happening, try adding this code:
Private Sub Form1_FormClosed(ByVal sender As Object, _
ByVal e As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
MsgBox("Form is closing")
End Sub
Make sure it is not crashing on launch.
I suppose the appropriate .net Framework is installed on the server?
If nothing is displayed because the application is terminating, it may be due to an unhandled exception. You can tell if the application has terminated by going into Task Manager and seeing if the application is running. If it has terminated, check the Windows Application Event Log. If you're lucky, you'll see an error entry and maybe even a stack trace in that log.
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.