Is it possible to have a Msgbox without a button on it in a console application. I would like to have a msgbox pop up and then disappear when the task has been completed. Or could I send the msgboxresult to some form of window that would just disappear when the file has been written?
MsgBox("The users on the domain are being gathered. A prompt will appear when all information has been gathered.")
Dim userFile2 As String = savefileDialog1.FileName & ".txt"
Dim fileExists2 As Boolean = File.Exists(userFile2)
Using sw As New StreamWriter(File.Open(userFile2, FileMode.OpenOrCreate))
For Each d As DirectoryEntry In de.Children()
sw.WriteLine(d.Name)
Next
End Using
If you want to have a console app with a GUI, I'd suggest that it might be easier to just make a WinForms app. Just create a new tiny WinForms app, make the default Form small as a dialog box and make it have only one invisible Close button.
Then you can just show the Close button when it's finished.
Just remember to disable the Control box on the Form (the X up in the top right hand corner) and handle any keyboard combination that could close it.
Edit: Or if for any reason you have to have it as a Console app, then you could still write a tiny separate app that just does the GUI part that you need and have the Console app start up the GUI app, sending over the text to display.
First, a quick point. A MsgBox is a modal dialog so will halt execution until the user responds, you can't use this.
In general "console" applications should be non-graphical.
You don't want to use a console application to disiplay a window. Since .Net 4.0 is available to you may want a WPF application that can write to the console.
There is a post about outputting to the console with WPF here on SO.
You should do your work on a different thread perhaps using a System.ComponentModel.BackgroundWorker. This will allow the Window to respond to user interaction and render while your task progresses.
Related
I have created my MS Access Program but I have multiple monitors and so do the other people who will be using the program.
Just so you know my forms are popup style, have no borders or record selectors and I am guessing this is where my issue comes in.
I would like to know if there is a way to ensure that when a user opens a form, the form will only open within the MS Access Window/Canvas on the active monitor?
I would also like to know if there is a way for my application to automatically adjust according to the users screen resolution?
As an example my Forms open perfectly when I am using the application on my main screen which has a resolution of 3840 x 2160 but if I open the application on my second screen which has a resolution of 1920 x 1080 the forms that open subsequently, such as the user form, then opens on the main screen so small that no one can read or see it.
Application is on Right monitor and User Form is Open on Left (Main) Monitor
The code I have used for the OnOpen Event is below:
Private Sub Form_Open(Cancel As Integer)
Dim Right As Integer, Down As Integer
Right = Screen.ActiveForm.WindowLeft
Down = Screen.ActiveForm.WindowTop
DoCmd.MoveSize Right, Down
End Sub
This was obtained from some research but I cant seem to bind everything to the Application Window/Canvas.
Thank you.
Well, if you only ever have one window open at one time, then you can do this with ease.
Remember, today most applications are SPA (what we call single page applications). We don't use (nor have) very often a main applcation window, and THEN a child window. For one, they tend to not be touch friendly, and it is VERY hard to move a window around with touch.
but, even desktop browsers even use some "kind" of tabbed interface. And so do most desktop applications. And by tabbed - I don't necessary mean across the top. This access screen shows a tab system from the left side:
So, Access now has a option to use tabbed interface.
And if you :
do NOT use pop windows.
Set access to use tabbed interface, eg this:
Then un-check the display tabs.
If you do above, then you WILL NEVER EVER see the access background window.
You see this:
However, keep this in mind:
The form you launch will re-size to the main size of the Access window - not the other way around.
All forms can't be popup
You are "SPA" like applcation.
So, most accounting and most desktop applications now work this way. And WHEN you launch a form, the window does not re-size tot he form, but remains the current applcation window size.
So, without ANY specials code, you can 100% hide the access background window.
And if you re-size the access application window, then the form will re-size to fill out the current form.
This might look quite bad in some cases - such as this:
Now for above, I on purpose made the form background green - just to PROVE and show that that Access background window NEVER will display with above options.
So, the main issue here?
You can 100% hide the access background window. And you can now do this WITHOUT specials code. Just a few settings.
On startup, you can hide the ribbon - or build a custom one - again your choice.
But, your forms MUST NOT be popup forms anymore.
So, hiding the access background window is very easy - it then becomes a question of form size - size forms re-size to application window size - not the other way around.
On the other hand, if you adopt a tabbed interface (accross the top or left side), then your main window is always in display, and you are in effect swapping out the form (a sub form) for display of that given form. You can write your own code, or use a new navigation form - which does this for you).
If you need to launch separate windows, then you could launch them as popup from this main form - but that main form will of course always hide the access background if you follow above.
If you wish to hide the ribbon, then on your main form - load event, you can add this code:
DoCmd.ShowToolbar "Ribbon", acToolbarNo
So, your main form (which hides access background) could be tabbed inteface (SPA) or it could be a launcher form, and each option clicked on could launch a form as popup - which can be dragged anywhere on your computer - including to the 2nd monitor if you wish.
So, either forms stay always in the main applcation window - but never see the background. Or you use above, and launch forms as popup.
I have an app built in VB in Visual Studio 2012 that works absolutely fine on my windows 10 desktop, but as soon as i use it on my windows 10 tablet i see a couple of issues :
1) any forms that were intended to be smaller than full screen are shown fullscreen anyway (almost as if you're not allowed any windows less than full screen) i can live with that if need be, but surely theres a way around it?
2) - the most important one - for some strange reason, i start my app, and when i click on a button let's say it opens form 6. once i finish what i'm doing the code closes the form 6, but the previous form is now hidden and all you see is the desktop. ie it's still running, it just lost its focus and must be selected again. I understand i could set the focus to the underlying form before closing form 6, but here's the problem : it can be one of several different forms calling form 6..... so how do i make the app stay aware of what form called form6 so that when done i can return focus there?
this doesnt seem to be a problem on the desktop so i've never encountered it before. i hope one of you experts has dealt with this before
I don't have enough points yet to comment. My guess for #1 is either resolution or DPI differences between the 2 screens, and I don't have experience with the latter.
As for #2 and keeping the form aware of who called it, this is how I do it, which may not be the best solution, of course. ;)
First any form that can have multiple callers has a variable defined like
Dim callingForm As New Form
I typically create an Initialize routine to handle as much as possible before loading a form and this routine is called with the parent form (Me) as a parameter.
Dim frm As New frmClient
frm.Initialize(Me)
frm.Show()
Me.Hide()
In Initialize, callingForm is set to the parent
Public Sub Initialize(parent As Form)
callingForm = parent
'whatever else you need to do to init...
End Sub
Then when you exit the form...
Private Sub exitForm()
'whatever other closing stuff you need to do...
callingForm.Show()
Me.Close()
End Sub
That should get you started.
fyi for anyone encountering this problem, i solved it myself and it didn't require any coding. It was a difference between how vb apps act when the tablet is in "TABLET" mode, and when tablet mode is switched off. So all that needed doing is switching off enhanced tablet mode in the windows 10 settings
We have a VB.Net Application with a Main form that should always be visible. However, we want to be able to display a succession of two dialog windows where we can close the first dialog as the second one appears. However, when doing that, the Main form gets sent behind whatever other applications are open and does not re-appear until the second dialog window closes.
We can correct this issue by keeping the first dialog window open behind the second one, but it’s not ideal. What are we doing incorrectly?
Try using dialog1.owner = mainform
I am writing an application in VB.Net in which a user can schedule emails to be sent in the future. Is there a way to keep my listener thread running in the background after the base form on the application is closed? I would also need to start up the listener when the system boots, but wouldn't want any forms to open at that time.
Example (desired) functionality: I open the application in the morning and schedule three emails, one of which should be sent in three hours, and the other two of which should be sent tomorrow morning. I close the application. In three hours, the first one sends. At the end of the day, I shut down my machine. When I turn it back on tomorrow morning, the other two are sent without me ever opening the application.
I am thinking I need to separate the listener into a service, but want to make sure there isn't an easier way before going down that road.
If I do end up having a separate service and application, can I create an installer that will install both at once?
In the options of your project, set the “Startup Object” to “Sub Main” instead of of a form name. You might have to disable the setting “Application Framework” first.
Now you have to launch the form manually because it’s no longer done automatically, but on the other hand you can now control when to launch it, and your application will exit when it reaches the end of the Main method (or when it’s quit explicitly) rather than when the form closes.
If all you want is to keep the program running, you could supply it with the definition for a TaskBar icon, and represent state in your application using the icon's graphic. It would appear over on the right next to the system clock.
Then it's just a matter of reconfiguring your development project so that the application close event is triggered off that icon's menu instead of off the fact that the form is closed.
Use a NotifyIcon control and when the user close the mainform capture the OnClosing Event to Ask the Question if he want to minimize to the tray or exit the application.
Here is the documentation of NotifyIcon control from Microsoft:
NotifyIcon Control
I have a possible solution for you here. In the form closing event you can place the following code:
Private Sub Form1_FormClosing(sender As Object, e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
Me.Visible = False
e.Cancel = True
End Sub
This will hide the form and allow it to run in the background until you shutdown the computer. To handle the restart and then send emails I'd suggest adding the emails to be sent to a text file that can be accessed after restart and then adding the program to startup. An even better solution might be to have 2 programs, one that is on startup and is always hidden that checks the text file every 15 minutes (for example) and a second program that is launched when a new email is to be added to the list and it appends the text file with new emails to be sent.
(Sorry if i am wrong, just proposing a probable solution here)
I think attaching a simple db to hold the email sending schedule information/date-time and loading the application at startup with Notification Icon (or without Notification Icon but with a shortcut to show user interface/form to feed the emails and schedule information/date-time, if required + BackgroundWorker, if you want the application to go to sleep mode and wake it later to send first scheduled email; after X hours). After sending first email update the db then exit the application. Check the db on startup to send the first email or go to sleep mode if pc boots before sending first email. But, if first email is already sent then send other two scheduled emails (check db date-time). This should do the job...
:)
I've inherited some VB.net code. My task is to find out why it isn't working. I have 2 applications. The first one
is run as a service, infinitely checking a table to see if there are any tasks to be handled. If it finds one, its supposed to fire off the second application to handle the task then returns to the loop and checks for another. Both these applications are forms but they do not show any windows. The problem I'm having is after the second application is finished, the first application never gets a signal it is done so it is waiting forever, thus it can't move onto the next task. If I go into TaskManager and kill the second application, the first one gets that notification and proceeds as it should. Below is how I am creating the process and waiting for it. I've tried several different ways of creating and waiting for the process (using a Shell/OpenProcess, WaitForSingleObject,etc) and I can't get it to work. I've searched all over the internet, StackOverflow and the MSDN site but nothing I've tried works. I've been messing with this for 2 days!!
Form 1 Load:
Dim ProcessProperties As New ProcessStartInfo
ProcessProperties.FileName = strExeFullPath
ProcessProperties.Arguments = " /project " & l_project
ProcessProperties.CreateNoWindow = True
Dim myProcess As Process = Process.Start(ProcessProperties)
myProcess.WaitForExit()
When Form2 is finished, it does a Me.Close() and Exit Sub in the load subroutine but the process is still showing in the TaskManager and never returns to Form1 so Form1 is in WaitForExit forever. I've tried closing every open file and connection and setting them to Nothing in Form2, Me.Dispose,etc. I've tried Application.Exit as the last line of Form2. That stupid thing will not die!! Why won't it DIE!!??!!
What am I missing?
If I go into TaskManager and kill the second application, the first one gets that notification
Keep your eyes on the ball, the real problem is that this second application is not exiting by itself. And thus myProcess.WaitForExit() isn't going to return. So this is not a problem in your code snippet.
Why the 2nd app doesn't want to quit is completely unclear from your question. Given that it is a Windows Forms app, do keep in mind that there is nobody to click the Close button of the form. Application.Exit() should make it stop, Environment.Exit() is a rude abort that cannot be veto-ed by a FormClosing event handler.
Anyway use this:
ProcessProperties.Arguments = String.Format("/project {0}", 1_project)
No leading space is required and code becomes more readable.
Cheers!
I suspect Form2 is trying to show some modal dialog (maybe a message box, maybe an unhandled exception box) before quitting. Since App2 is launched by App1, which is a service, Form2 cannot interact with the desktop and just sits there waiting for a button click that will never happen.
Try to allow the App1 service to interact with the desktop (you can find that option on the Log On tab of the service properties dialog box) and check if Form2 actually pops up a dialog before quitting.