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.
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 have written a WinForms driver safety application for a windows tablet device that will blank the screen (display a full screen blank topmost window) when it detects that the car is moving at say more that 15km/h (using the tablets GPS).
The software has worked fine under Windows 7 but I'm struggling a bit to get it working under Windows 8. My first challenge is to display the blank screen when the Metro start menu is currently displayed. So if the user has the Metro start menu displayed and the car starts moving > 15 km/h my blank screen should display... I need to steal the focus from the metro interface and display my blank window on the desktop.
To test this I wrote a simple vb.net app in 2010. It had a form with a timer firing every 3 seconds. In the Tick event I had the code:
Beep()
Me.Activate()
When I ran this with the debugger and pressed the windows key to show the Metro Start Menu, it worked... The focus switched back to the desktop (and my window). However, when I ran this without the debugger and did the same thing I could hear the beeps but the focus never switched back to the desktop.
Any ideas why the behaviour would be different? Any ideas on how I replicate the same behaviour I get when the debugger is attached?
I have tried a few things like AppActivate, setting the form TopMost, BringToFront but unfortunately this hasn't worked.
The only half solution I have come up with is to send a windows button keystroke but this has other issues.
Windows specifically tries to prevent applications from stealing the foreground from other apps. See the SetForegroundWindow documentation for commentary on this and the factors that can let an application come to the foreground (all of the methods you are trying essentially come down to a SetForegroundWindow call).
Note that one of the explicit blocking circumstances is "The foreground process is not a Modern Application or the Start Screen."
This works for you when debugging because "The process is being debugged" is one of the cases which explicitly allows foreground privileges.
Because this is a generally user-unfriendly thing to do there isn't a good general purpose way to bypass this behaviour and steal the foreground.
Likewise, normal apps cannot run on top of Modern applications or the start screen.
You may be better off locking the system by calling the LockWorkStation function.
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.
I am developing a windows service, in VB.NET, that launches a legacy application that performs some work. The service acts as a wrapper around the legacy app allowing users to automate an otherwise manual operation.
Everything is working great, except occasionally the legacy app displays a messagebox. When it does this the process halts until the message box is closed.
As the service will be running on a server there will be no user to close the message box.
The service launches the legacy application in a System.Diagnostics.Process.
Is there way to detect that a message box has been displayed by a process that I have started using System.Diagnostics.Process? And is there a way to close the messagebox through code?
I also found that EnumChildWindows does not return the MessageBox. But I found a site that showed me how to do it. http://vbcity.com/forums/t/105842.aspx
You want to call GetWindow passing in GW_ENABLEDPOPUP. It worked like a charm. Thanks to Scott Waletzko!
Use FindWindow to find the app, the use EnumChildWindows to enumerate all it's childwindows until you find the messagebox (if the messagebox isn't a direct child of the main window of the app you might have to have recursive calls I think).
You might be able to skip the FindWindow call and instead use the MainWindowHandle property of the Process, but I haven't checked if that works.
A good tool for looking at all this is Spy++ which can help you see some information you can get hold of about a running process.
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?