What i'm trying to do, is a simple program where i have 2 textboxes, and a button.(there is more but no need to say for resolving my problem)
When i write text in the 1st textbox and click the button, it will be written in the 2nd textbox. Everything is ok here.
Now, when i run this program more than once, i want the text to be written in the 2nd textbox of the others programs.
Sorry for the bad explaination i gave you before, hope it's better :)
OLD DESCRIPTION
i'm actually trying to make a program that works pretty much like a
messenger (basically 2 textboxes, 1 to send, 1 to view, and a button
to send) and i can't figure out how to link the program with itself
(copies). I want it to be able to read the textboxes contained
in the other copies and i don't want it to be 1 program with 2 forms,
but 1 single form, running severeal times (2 or more) How can i
do that? /!\ NOTE : It will be on a single computer, just like 2
forms!
I am assuming you are doing this in WinForms and only running one executable.
Sounds like you you want to create a single instance of a class that is shared between several forms. It should raise an event when the values change. After you create each instance of your form you pass in the class. In the form you would declare it With Events. When one form updates the class it would raise an event notifying the other forms to refresh themselves.
If you are familiar with WPF and MVVM this sort of design would be a little cleaner, but that takes some time to get up to speed on.
This design would not be appropriate if you want to run seperate applications and communicate between them.
You will have to do some kind of IPC, respectively remoting.
You could use:
anonymous pipes
named pipes
UDP
TCP
WCF (would be overkill IMHO)
windows messaging (would be the easiest way)
Related
How can I communicate between VB.net and GlovePIE?
I know that you can send OSC (Open Sound Control-It isn't just for sound) data in GlovePIE so if you could send/receive data in VB.net without any libraries that would work but I cannot find any resources.
Please post any code that you can.
EDIT: All I want is a basic way to communicate between GlovePIE and VB.net and I found that you could send OSC data in GlovePIE but you cannot in VB.net I would accept any help that I can get. If you have a better method, feel free to tell me. I am using this guide to send the data.
After lots of creative thinking, and hours wasted, I finally came up with an idea. (Thanks to spajce for helping me realize there is no perfect solution, and I had to think outside of the box to make this work.) This is what I am going to do. (I have not written the code yet, but I will try to submit it as soon as I write it.)
How I am going to set it up:
I will have a form in VB.net that will send data to the COM port. It's GUI will have the user select the COM port and have a button to connect.
In my GlovePIE script, I will have it automatically hide itself.
For data transfer to VB.net:
GlovePIE will tell if the form is selected using the Window.Title property. If it is, it will emulate a key press. The form will be looking for the keypress.
For Data Transfer to GlovePIE:
The form will change the Me.text property to something that has happened. For exaple, I'm building a robot and if the ping sensor senses something, my Aduino will send the data over serial, to VB.net, which will change the title to "Robot Connect-OBJECT DETECTED" GlovePIE will know the multiple names the form might be, and when searching to see if it is active, it can tell if something has been detected. VB.net will change the title back to "Robot Connect" after GlovePIE signals it has recived the signal.
There will be some bugs, but VB.net is smart enough to tell if another window is the active one. If you are browsing this question, you may have to adapt this. I will have to put a couple of safety features to prevent the robot from not stopping when the VB.net window loses focus.
Thanks to anbody who tried to help.
I am retrofitting unit testing into a fairly complex system designed and written by other developers in VB.net. I am trying to develop unit tests for the GUI forms using NUnit and the NUnit Forms extension. (I've been looking at c# examples that are fairly easy to port over if you have a solution but don't know VB syntax as long as it uses NUnit classes)
I will try and explain what I am doing but first a brief description of the program. It basically monitors server activity. You need to connect to a server via a modal form with IP and Port fields(amongst others). Once you have connected to a server other parts of the program unlock and become usable (such as configuration of the server).
Desired process: Load program > click connect button > modal connect form loads > enter details > click OK to connect > main form updates to logged-in state > other functionality
The problem is that I cannot test the functionality of the connect form and then the logged-in functionality of the program. I can test that it loads the modal connect form correctly; enters the details and clicks OK (all fine so-far) but it does not appear to logically progress the program. The modal form just closes again seemingly without running the connect code from the program back-end and I’m back at the main menu not logged in to anything.
I have a feeling that I’ve either missed something really obvious or that it’s simply not doable in NUnit. I have trawled the internet in search of anything similar but the closest was another SO thread that was really generic. Without being able to actually test the logged-in version of the program, I'm at a major hurdle.
Another issue is handling message boxes that don’t have unique identifiers (e.g. “are you sure you want to exit?”); these also seem to be a major pain in the arse with NUnit
(If it makes any difference, I’m running the tests as a stand-alone project using a reference to the executable file of the built project, not the actual source)
Can post some of my testing code if required.
IMHO the best approach to make GUI classes feasible for unit tests is to apply the Model-View-Presenter pattern and factor almost every program logic out of the form (=View) class to a separate Presenter class. Then you can unit test the Presenter class without the need for tools like "NUnit Forms".
Read Michael Feathers' article "The Humble Dialog Box" for an example in C++, you can easily apply that to Winforms, I guess.
I'm not sure about NUnit forms, but using the White library (which also works with NUnit), you're able to test the application by running the exe and mimicking user actions. The application runs normally so all application logic is performed.
Here's some example code for launching an app with White:
Dim app = White.Core.Application.Launch("MyApp.exe")
Accessing a form from your app:
Dim mainForm = app.GetWindow(SearchCriteria.ByAutomationId("MainForm"),
InitializeOption.NoCache)
Performing an action such as clicking a menu item:
mainForm.MenuBar.MenuItem("Edit", "Jobs...").Click()
Getting a control and validating its state:
Dim someTextBox = mainForm.Get(Of TextBox)(SearchCriteria.ByAutomationId("txtValue"))
Assert.IsTrue(someTextBox.Text = "12345")
I'm not sure if NUnit Forms has similar capabilities, but if not, maybe you should look into White. I ran into some issues setting it up so make sure to read the documentation carefully (not very exhaustive unfortunately) before setting it up.
I have 4 classes, each with a couple of methods (all the same, they implement a common Interface) and a Dictionary<> containing stuff the instances need to know to do work. They operate serially, "A" finishes and then writes some stuff to state (either file or a DB), then "B" does its work, then "C", then "D". Right now a console app just runs each.
I will soon come on a time when I need to put something between "A" and "B", and later "C" and "D". You get the idea.
I thought that Windows Workflow on Framework 4.0 would be a good candidate for simple sequence orchestration. So I added a new XAML file, fired up the designer, and.... I'm not sure what to do next. I just want to instance objects and set their Dictionary and run them.
How can I get started with that? Simple orchestration searches on Google are not helping.
Thanks.
In order to help the next WF newbie:
Open the designer.
Drag a "Sequence" onto the design surface.
Drag an "InvokeMethod" inside the Sequence.
Target type should be null for Instance Types.
Target object should be "New my.namespace.my.class" (note New is VBasic syntax, required even if you are doing C#)
MethodName should have the name of the method you want to call.
Get Properties and click the elipsis and add the properties in the same order as they are specified in the class definition in your code.
Done.
I stumbled for a while until I found the right word to Bing for - InvokeMethod is the sweetness that lets you run custom code as an activity. There are at least 99e99 other ways to do it I am sure, but this is what works for me.
Thanks.
We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.
I am working on a VB.NET batch PDF exporting program for CAD drawings. The programs runs fine, but the architecture is a mess. Basically, one big function takes the entire process from start to finish. I would like to make a separate class, or several, to do the exporting work.
Here's the problem:
Sometimes the pdf file which will be created by my program already exists. In this case, I would like to ask the user if he/she would like to overwrite existing PDFs. I only want to do this if there is actually something which will be overwritten and I only want to do this once. In other words, "yes" = "yes to all." It seems wrong to have the form (which will be calling this new PDF exporting class) figure out what the PDF files will be called and whether there will be any overwrites. In fact, it would be best to have the names for the PDF files determined as the individual CAD drawings are processed (because I might want to use information which will only become available after loading the files in the CAD program in the background).
Here's the question:
How should I handle the process of prompting the user? I would like to keep all GUI logic (even something as simple as a dialog box) out of my PDF exporting class. I need a way for the PDF exporting class to say, "Hey, I need to know if I should overwrite or skip this file," and the form class (or any other class) to say, "Um, ok, I'll ask the user and get back to you."
It seems there ought to be some pattern to handle this situation. What is it?
Follow-ups:
Events: It seems like this is a good way to go. Is this about what the code should look like in the PDF exporting class?
Dim e As New FileExistsEventArgs(PDFFile)
RaiseEvent FileExists(Me, e)
If e.Overwrite Then
'Do stuff here
End If
A crazy idea: What about passing delegate functions to the export method of the PDF exporting class to handle the overwrite case?
You could use an Event, create a custom event argument class with a property on it that the application can call. Then when your app is handling the event prompt the user and then tell the exporter what to do. I'm a c# guy so let me give you a sample in there first:
void form_Load(object sender,EventArgs e)
{
//We are subscribing to the event here. In VB this is done differently
pdfExporter.FileExists+=new FileExistsEventHandler(pdfExporter_fileExists)
}
void pdfExporter_fileExists(object sender, FileExistsEventArgs e)
{
//prompUser takes the file and asks the user
if (promptUser(e.FileName))
{
}
}
Your PDF making class should raise an event. This event should have an eventargs object, which can have a boolean property called "Overwrite" which the GUI sets in whatever fashion you want. When the event returns in your PDF class you'll have the user's decision and can overwrite or not as needed. The Gui can handle the event anyway it likes.
Also, I commend you for working to keep the two seperate!
So the appropriate method on your class needs an optional parameter of
[OverwriteExisting as Boolean = False]
However your form will need to handle the logic of establishing whether or not a file exists. It seems to me that this would not be a function that you would want encapsulated within your PDF export class anyway. Assuming that your form or other function/class ascertains that an overwrite is required then the export methos is called passing True as a Boolean to your export class.
You could do a two phase commit type of thing.
The class has two interfaces, one for prepping the filenames and filesystem, and another for doing the actual work.
So the first phase, the GUI calls the initialization interface, and gets a quick answer as to whether or not anything needs over-writing. Possibly even a comprehensive list of the files that will get over-written. User answers, the boolean variable in the other responses is known, and then the exporter gets to the real work, and the user can go do something else.
There would be some duplication of computation, but it's probably worth it to get the user's part of the operation over with as soon as possible.
You can't keep the GUI stuff out of the PDF Exporting Code. but you can precisely define the minimum needed and not be tied to whatever framework you are using.
How I do it is that I have a Status class, and a Progress class. The two exist because Status is design to update a status message, and the Progress Bar is designed to work with a indicator of progress.
Both of them work with a object that has a class type of IStatusDisplay and IPrograssDisplay respectfully.
My GUI defines a object implementing IStatusDisplay (or IProgressDisplay) and registers as the current display with the DLL having Status and Progress. The DLL with Status and Progress also have two singleton called NullStatus and NullProgress that can be used when there is no UI feedback wanted.
With this scheme I can pepper my code with as many Status or Progress updates I want and I only worry about the implementations at the GUI Layer. If I want a silent process I can just use the Null objects. Also if I completely change my GUI Framework all the new GUI has to do is make the new object that implements the IStatusDisplay, IProgressDisplay.
A alternative is to raise events but I find that confusing and complicated to handle at the GUI level. Especially if you have multiple screen the user could switch between. By using a Interface you make the connection clearer and more maintainable in the longe.
EDIT
You can create a Prompt Class and a IPromptDisplay to handle situation like asking whether you want to overwrite files.
For example
Dim P as New Prompt(MyPromptDisplay,PromptEnum.YesNo)
'MyPromptDisplay is of IPromptDisplay and was registered by the GUI when the application was initialized
If PromptYesNo.Ask("Do you wish to overwrite files")= PromptReply.Yes Then
'Do stuff here
End If