I'm trying to pass messages between a vba application (in powerpoint- during a slideshow) and a .net application I wrote.
The only method I could think of, is sending keystrokes.
However, this method causes the powerpoint to lose focus.
can you suggest a solution ?
If all happens on the same machine, the easiest way maybe is to let the PPT write its status into the registry from where the other application reads it out (GetSetting(), SaveSetting()).
If PTT and the other process run on different machines, you could think of writing out the status into a small text file which can be read out asynchronously.
Another way of (synchronous) communication between two processes/applications on different machines is to use sockets and send information across the network.
I found an interesting way of communication between vba and .net, without file system manipulation, sockets or external objects.
First, We register powerpoint evets, as such:
http://www.vbaexpress.com/kb/getarticle.php?kb_id=327
Second, We update the clipboard in VBA on the presentation-start event:
http://word.mvps.org/faqs/macrosvba/ManipulateClipboard.htm
Third, We use a clipboard a listener on .net:
How do I monitor clipboard content changes in C#?
Last, We restore the original clipboard value on presentation-end event
Related
Currently i'm working on a security monitoring app that continuously monitor new processes created.
For that im using wim and event watcher, witch works fine in VB.NET.
But there are 2 features that im missing.
I need to monitor process API calls, and I've been searching the web like mad, and come up empty.
Basically i need to monitor process WaitForSingleObject, LoadLibraryA, CreateProcessW and WriteProcessMemory. And registry access/changes as well.
Im hoping this can be done without a system wide hook, but form what i can find, it cannot be done via WMI.
So the question is, how to, and what can i do with managed code.
I'm gonna focus on the second point as i don't have experience on your first.
For checking if a process is signed i am using the sigcheck.exe from Mark Russinovich, because of the various methods it uses to verify files. Some are catalogsigned, some have the key embedded, there is iirc another weird method. There is no easy way to do it yourself. Had weird false detections with trying self-built methods to cover all possibilities. Hope that info helps
I'm attempting to make a program to control the basic functions of a computer through a server/client method. I just need to send a string from the server to the client and vice versa. Every example I've found is really old and no longer works, or is poorly explained, or is in C#.
I almost have a working example as is, but I'm running into a threading issue where it won't let me modify elements in the UI after I've opened my thread for the connection from server to client or client to server. No idea how to fix this and I'm out of options.
Essentially I need a method of sending text from one IP/port to another in a server/client architecture.
The clue to solving your issue is probably here: "I almost have a working example as is, but I'm running into a threading issue where it won't let me modify elements in the UI after I've opened my thread for the connection from server to client or client to server."
You cannot access controls (UI elements) created on one thread directly from another thread. So if you have another thread and you want to update an element in the UI, you need to use the Control.BeginInvoke Method.
You didn't post any code, so I won't try and give you an example that may be utterly useless in your case, but there's a good article on MSDN here - How to: Make Thread-Safe Calls to Windows Forms Controls. This is for Windows Forms, nut the principals are the same for any application.
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.
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'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.