I have created custom object in Python using pywin32.
while calling that object takes some times.
Following is my try at making that asynchronous with respect to application stat so that while macro is running application doesn't freez.
Sub demo()
demofunction
End Sub
Function demofunction()
Dim demoobj As Object
Do While demoobj Is Nothing
DoEvents
Set demoobj = CreateObject("Python.DemoObj")
Loop
Debug.Print demoobj.Hello
End Function
Obviously the code is not working in terms of asynchronous run. Is this even possible any how?
Above code however working fine while freezing the application for a while.
Vba is single threaded but you can play some tricks to make it appear multi-threaded, after all rising star web server Node.js serves off of one thread but gives impression of multi-threaded.
1) So, you could put some Python component behind a web server and then use MSXML2.XMLHTTP60 asynchronously. Private WithEvents oXHR As MSXML2.XMLHTTP60 comes in handy here. (Note you need to declare this as a member of a class to use WithEvents)
2) You could shell out to a process (which gives you another thread) and call the Python component that way, then you use some Windows API calls to periodically check if the process has completed.
Related
Folks,
I'll been fighting this for a few weeks now. We have a proprietary corporate app running on thin clients in our organization. From this app we can apply VBA scripting behind the scenes to do simple functions. In the past adding buttons to open IE and direct them to certain web sites to enter data, open Calc and etc.
Recently I have been working the code below. It was developed on the Server using a RDP session which launches the full desktop and explorer.exe. What I have noticed that if explorer.exe isn't running then the code bombs at line in the function that reads "For Each oWin In oShApp.Windows " with "Run-time error '429'".
However if I script to start explorer.exe (which is bad because it enables the Start-bar and Task-bar) on the ThinClient which launches the desktop and full capabilities and it runs just fine as the Thin Client users that are logged in.
I have read a little bit about the "Limited Shell" that runs when using a remoteapp and not the full desktop and was wondering if there was anyway around it, without enable the start-menu and taskbar?
See the code below.
Thanks for the help, CreteIT
Private Sub cmdHomePage_Click()
Dim ie As Object
Dim sMatch As String
sMatch = "http://www.companyweb.com"
On Error Resume Next
Set ie = GetIEatURL(sMatch & "*")
On Error GoTo 0
If Not ie Is Nothing Then
ShowWindow ie.hwnd, 9
BringWindowToTop ie.hwnd
Else
Dim strHome
Dim strAPP
strHome = "c:\progra~1\intern~1\iexplore.exe www.companyweb.com"
strAPP = Shell(strHome, vbNormalFocus)
End If
End Sub
Function GetIEatURL(sMatch As String) As Object
Dim ie As Object, oShApp As Object, oWin As Object
Set oShApp = CreateObject("Shell.Application")
For Each oWin In oShApp.Windows
If TypeName(oWin.Document) = "HTMLDocument" Then
Set ie = oWin
If LCase(ie.LocationURL) Like LCase(sMatch) Then
Set GetIEatURL = ie
Exit For
End If
End If
Next
Set oShApp = Nothing
Set oWin = Nothing
End Function
I work on the RemoteApp team at Microsoft. I'm not quite clear whether you're running this script from an actual RemoteApp session or your own setup that has a different shell that replaces explorer.exe (or perhaps no shell at all), but either way the answer is about the same.
The Shell.Application ActiveX object your script is trying to instantiate appears to be implemented by the shell - typically explorer.exe. If that isn't running, the COM runtime won't be able to create an instance of the object, and when you try to activate it you'll get an error.
The obvious solution is to run explorer.exe but, as you observed, that also includes the taskbar and start menu, which you might not want. RemoteApp runs its own shell replacement (rdpshell.exe), but that doesn't implement Shell.Application, so just running your application under RemoteApp won't fix the problem.
There are a few potential solutions I can think of:
If you're not using RemoteApp, you could write your own replacement shell that does implement Shell.Application. This is quite a lot of work and there might not be a lot of documentation around on how to do it properly. If you already have a replacement shell, you might be able to extend it to implement Shell.Application.
You could use a different method to enumerate windows. Unfortunately this probably means Win32 (via the EnumWindows function), which isn't directly accessible from VB scripts; you might have to create an ActiveX object that implements the behavior you want, and invoke it from the script.
Similar to option 2 but more heavyweight - you could make that ActiveX object implement the whole Shell.Application interface - even though it isn't actually the shell - and register it on the remote machine. I can't guarantee you won't run into problems if you do this though; it isn't something I've tried before.
None of these solutions are ideal, unfortunately, but hopefully something lets you do what you need to.
I have a BackgroundWorker routine that performs a lot of things and call ThreadSafe functions to update UI controls. In some points of that routine I call some subroutines to write log information into a SQL table, using the Parallel Library to make them in another Thread. It´s functioning like a charm.
The threaded LOG calls are like this, where Log_Compressed_File() is a subroutine:
Dim Log_Threaded as Thread = New Thread(Sub() Log_Compressed_File(Username, UserAreaCode, Filename))
Log_Threaded.IsBackground = False
Log_Threaded.Priority = ThreadPriority.Highest
Log_Threaded.SetApartmentState(Threading.ApartmentState.MTA)
Log_Threaded.Start
As shown above, each log call is made using 5 lines of code, defining the new thread itself and some important parameters.
My questions are:
1) can I produce a Sub to address these calls, trying to reduce the lines of the main routine?
Just to make it clear: I have more than 35 LOG calls within the main routine and, if each one would utilize 5 lines of code, I will have 175 lines, when I could have only the original 35 calls to a new subroutine that could address the new thread.
2) Can I call that subroutine from within the BackgroundWorker without to call a delegate function (ThreadSafe) like I use in UI updates?
The function like shown above can be performed within the BackgroundWorker without to a DELEGATE function (the LOG_COMPRESSED_FILE is a normal Sub, not a Delegate call).
Thanks in advance for any help!
Yes. Just write a method with the same three parameters as your Log_Compressed_File method and then put that code into that method.
Yes. Do you understand why you need to use a delegate at all? The point is that you cannot access the Handle of a control on any thread other than the one it was created on. Invoking a delegate ensures that code accessing the control's Handle is executed on the correct thread. If you're not accessing a control then there's no Handle so why would it matter what thread you execute the code on?
I'm building a server and a client for a chat that runs on Tcp and Sockets, I want the client to handle more than one connection (to servers) so I made a class called "Client" to manage the async connection, so that I can run more instances at the same time like:
Dim ConnectionToServer1 as new Client
Dim ConnectionToServer2 as new Client
Since it's async when the the "connection" receives a message it generates an event (AsyncCallback) where I can convert the received bytes into a string.
The problem is: I've tried to set this string to a RichTextBox on my Form from inside the Client class, but nothing happens, I've tried to create a delegate in the form code but nothing works, the only way I was able to put the received message in the RichTextBox is by creating a public variable called LastMessage in the Client class where the last message is stored (every time it receives a message, the sub overrides the string), and then running a thread created by the Form which keeps checking for data (since the thread has been created by the form it has access to the controls, including the RichTextBox, right?)
Although I find this a bit clunky, is there any other way (through delegates maybe?) I can do it?
Here's some code:
Client class: http://pastebin.com/GF9um8Ss
Form code: http://pastebin.com/xW7mDj8j
Sounds like you started down all the right paths.
Now, on threaded applications one of the challenges that you will face is you can have tons of worker threads, but only the main, UI thread can actually make any updates to the UI. So keeping that in mind, if you have async code that needs to update the ui you will need to use what is effectively a delegate.
You can do this using tasks these days a lot easier, so read up on the Task Parallel Library, but essentially you need a delegate/task that is marshaled to run on the ui thread to handle the UI updates.
Set this global property as false
Control.CheckForIllegalCrossThreadCalls = false
this will let you edit any control of your form from any thread
I currently have made an all in one peer to peer 'chat' program. It currently uses a timer to receive messages, and a client to send them to other people running the program. I would really like to make this whole system async so I stop getting complaints of the main executable freezing and such.
I have pasted all of my code(VB.net) here: http://pastebin.com/EcrtCgVc
Could someone assist me in making this system faster, async, or done better.
If you would like a link to the dropbox of the full source, I can provide this also.
I would suggest you to take a look at this example project:
Asynchronous Server Socket Example
http://msdn.microsoft.com/en-us/library/fx6588te%28v=vs.110%29.aspx
You can use it together with this example:
Asynchronous Client Socket Example
http://msdn.microsoft.com/en-us/library/bew39x2a%28v=vs.110%29.aspx
You may need to use async methods in your server code and you may use Delegate Sub to make your server run in another thread, so main thread(UI) will be still responsive.
http://msdn.microsoft.com/en-us/library/ms172879.aspx
Without looking at your code, I am also working with socket programming.
"Do not mix GUI code with business code."
Like jgauffin said, you should not combine code that run in the background with the GUI.
For example, if you're using a socket to accept data, or connections, you must run that method on a new thread.
Example...
Public Sub YourMainSub()
Dim threadOne As New System.Threading.Thread(AddressOf ListenCode)
threadOne.Start()
'Put other code here.....
End Sub
Public Sub ListenCode()
Dim newPerson = yourServer.Accept()
'Or
Dim newData = yourServer.Receive()
End Sub
Sorry if the code isn't exactly correct. I typed that by memory.
According to the answers to another question, the VB user interface cannot be updated if the thread that created it is busy: hence why big computational jobs usually have to go in a background task.
Here's what's mystifying then. I have the following code. It's called over in-process COM, like this
client calls showform()
client does loads of work, freezing up its own UI in the process
client finishes work, returns to updating its own UI
At step 2, the VB form is there but frozen - you can't interact with it. At step 3, the VB form becomes usable. But why is this? Surely the thread of execution has returned to the client? If the client is somehow handling events for the form, by what magic did it know what events to handle and where to send them?
<ComClass(ComClass1.ClassId, ComClass1.InterfaceId, ComClass1.EventsId)> _
Public Class ComClass1
Public Sub New()
MyBase.New()
End Sub
Private f1 As Form1
Public Sub showform()
f1 = New Form1()
f1.Show()
End Sub
End Class
The magic you speak of is the basis of Windows programming. My answer to your previous question explains why and how you can fix this. When making a COM call the client application just imports your procedure into their application. Whether they create a form by typing the code themselves or whether they create a form using code you have typed it doesn't change the nature of the object/owner relationship. A COM call to your showForm will still make f1 belong to the thread which made the call (client UI thread). The window handle for that window will still be the responsibility of the UI thread that created it (the client).
Creating a form only makes a mailbox (window handle). A UI thread is a mailman (message pumping loop). You aren't providing the client with a new mailman, just a new object with a mailbox. When the client program creates the window by making the COM call to your procedure it (the client UI thread) takes responsibility for delivering messages to the new form's mailbox (registers its window handle with the main UI thread). Their mailman still needs to send you messages to make your visual objects work. If he is busy trying to calculate pi to a trillion decimal places then your object freezes like everything else on his mail route.
check the form.load event. the form loads and runs code... that is where it freezes.