ActiveX DLL (for Olaf)
in [Visual Basic]
|
From: David on 25 Sep 2009 12:03 Found DirectCOM.dll on your web site. Will give it a shot. David "David" <dw85745NOT(a)earthlink.net> wrote in message news:O5I9ZYfPKHA.1876(a)TK2MSFTNGP06.phx.gbl... > Olaf: > > Thanks for your time and response. > > You probably already answered my question > -- last part of response little confusing for me -- but here's my problem. > > I have a set of tools that currently are part of a main VB program. > The main program interfaces realtime and because of the amount of CPU > clock ticks available, when I use my tools, I periodically get a conflict. > > Since I don't need a user interface I ruled Out an ActiveX control. This > leaves ActiveX DLL or ActiveX EXE that can be called from within my main > VB. Based on your response, since the ActiveX DLL would not be on a > separate thread, that would only leave me with an ActiveX EXE. > > You do however mention DirectCOM.dll (this is where I'm confused): > > > For threading-purposes (in case you want to use >> Public Classes of your ActiveX-Dll as ThreadClasses >> and avoid putting them into an ActiveX-Exe-project) >> you can use DirectCOM.dll, to start Class-Instances >> directly from ActiveX-Dlls regfree. This alternative >> Threading-approach can help settle potential "deployment >> and registering-issues" of ActiveX-Exes (for example >> on Vista-Targets). > > Can (How do) I create a DirectCOM.dll from VB5?? > > David > > > "Schmidt" <sss(a)online.de> wrote in message > news:uhQK5GfPKHA.4428(a)TK2MSFTNGP02.phx.gbl... >> >> "David" <dw85745NOT(a)earthlink.net> schrieb im Newsbeitrag >> news:ug7A3lePKHA.1372(a)TK2MSFTNGP02.phx.gbl... >> >>> Is an ActiveX DLL (while running in the same address space) >>> running as a separate thread From the Main Program? >> >> No, not by default. >> Though there are situations, where an *debugged* >> ActiveX-Dll-project (if not placed within the same >> VB-Projectgroup, but in a separate IDE-instance instead) >> is running on a separate Process/thread. >> >> But in "binary-mode" an ActiveX-Dll is running as the so >> called "InProcess-Server" within the same Process- >> Address-space (on the very same, single VB-MainThread). >> >> Just take a look into the Taskmanager, how many threads >> are running (not in the IDE, but in the compiled Main.exe- >> binary). >> >> For threading-purposes (in case you want to use >> Public Classes of your ActiveX-Dll as ThreadClasses >> and avoid putting them into an ActiveX-Exe-project) >> you can use DirectCOM.dll, to start Class-Instances >> directly from ActiveX-Dlls regfree. This alternative >> Threading-approach can help settle potential "deployment >> and registering-issues" of ActiveX-Exes (for example >> on Vista-Targets). >> >> Olaf >> >> >> >> > >
From: Schmidt on 25 Sep 2009 12:46 "David" <dw85745NOT(a)earthlink.net> schrieb im Newsbeitrag news:%23JbMGnfPKHA.4692(a)TK2MSFTNGP06.phx.gbl... > Found DirectCOM.dll on your web site. Will give it a shot. Since you were talking about "realtime", you probably want to place the "device-interaction" within a separate ThreadClass. This usually involves a highfrequent "WaitLoop", constantly asking the "realtime-device" for new data in short (1-3msec) intervals. The retrieved Device-Data should then (usually) also be visible/reachable within the MainThread (your MainApp-GUI). In that case DirectCOM.dll can be of help, since it exports a: StartCOMObject call, which is able to start a Public Class regfree on a new Thread. There's a convention in that case - the Public ThreadClass must have a: Public Function ThreadMain(Byval UserData as Long) End Function The Thread (hosting that ThreadClass) remains then alive, as long as you remain "looping" or "waiting" in the Public ThreadMain-Procedure. So your ThreadMain should be filled with something like this (regarding "Realtime-Device-interaction"): Public Function ThreadMain(Byval UserData as Long) 1. SetUp a shared memory Area (usually an UDT-Array) 2. InitYourDevice 3. EnterDeviceLoop (placing new Data within the shared Array) The above loop should check cyclically not only for new DeviceData, but also for something like an "ExitCondition" usually done with a Flag of the SaredMem-Area (the UDT-Array) End Function '<--Thread-Exit (also terminating this ThreadClass) If you want an example, you could write some simulation-code, that somehow mimicks (mocks) your Device (principically). Working singlethreaded in a small TestApp, involving DoEvents if you want, just that the principle can be seen. I could then expand this small Demo of yours into a threaded solution, involving DirectCOM and a separated AX-Dll, containing your "Device-Class", just that you get an impression how all that stuff works. Olaf
From: David on 25 Sep 2009 14:03 Olaf: Thanks for the offer. My initial idea was to move all tool functions (methods) to a separate dll thread. For initial tool placement I don't seem to have any problems. Only issues when moving the tool after intial placement (more clock ticks). My thoughts were that I can set the tool properties in the main thread (handled both by menu selection and / or format using a separate model form). All other tool execution (moving or form refresh) would be a call to the tool functions contained in DirectCOM.dll from the main thread Paint event. This would move all tool code processing into a separate thread, -- but --not sure whether the main thread will still have problems since it may be waiting on the callback from DirectCOM.dll to go to the next code line?? Am I wasting my time with above or is an example (per your kind offer) needed to work this out?? "Schmidt" <sss(a)online.de> wrote in message news:eaS$HCgPKHA.504(a)TK2MSFTNGP06.phx.gbl... > > "David" <dw85745NOT(a)earthlink.net> schrieb im Newsbeitrag > news:%23JbMGnfPKHA.4692(a)TK2MSFTNGP06.phx.gbl... > >> Found DirectCOM.dll on your web site. Will give it a shot. > > Since you were talking about "realtime", you probably want > to place the "device-interaction" within a separate > ThreadClass. > > This usually involves a highfrequent "WaitLoop", constantly > asking the "realtime-device" for new data in short (1-3msec) > intervals. > The retrieved Device-Data should then (usually) also be > visible/reachable within the MainThread (your MainApp-GUI). > > In that case DirectCOM.dll can be of help, since it exports a: > StartCOMObject call, which is able to start a Public Class > regfree on a new Thread. > > There's a convention in that case - the Public ThreadClass > must have a: > Public Function ThreadMain(Byval UserData as Long) > > End Function > > The Thread (hosting that ThreadClass) remains then alive, > as long as you remain "looping" or "waiting" in the Public > ThreadMain-Procedure. > > So your ThreadMain should be filled with something like this > (regarding "Realtime-Device-interaction"): > > Public Function ThreadMain(Byval UserData as Long) > 1. SetUp a shared memory Area (usually an UDT-Array) > 2. InitYourDevice > 3. EnterDeviceLoop (placing new Data within the shared Array) > The above loop should check cyclically not only for new > DeviceData, but also for something like an "ExitCondition" > usually done with a Flag of the SaredMem-Area (the UDT-Array) > End Function '<--Thread-Exit (also terminating this ThreadClass) > > > If you want an example, you could write some simulation-code, > that somehow mimicks (mocks) your Device (principically). > Working singlethreaded in a small TestApp, involving DoEvents > if you want, just that the principle can be seen. > > I could then expand this small Demo of yours into a threaded > solution, involving DirectCOM and a separated AX-Dll, > containing your "Device-Class", just that you get an impression > how all that stuff works. > > Olaf > >
From: Schmidt on 25 Sep 2009 19:33 "David" <dw85745NOT(a)earthlink.net> schrieb im Newsbeitrag news:O9asGqgPKHA.764(a)TK2MSFTNGP02.phx.gbl... > My initial idea was to move all tool functions (methods) to a separate dll > thread. > > For initial tool placement I don't seem to have any problems. > Only issues when moving the tool after intial placement (more clock ticks). > > My thoughts were that I can set the tool properties in the main thread > (handled both by menu selection and / or format using a separate model > form). All other tool execution (moving or form refresh) would be a call to > the tool functions contained in DirectCOM.dll from the main thread Paint > event. > This would move all tool code processing into a separate thread, -- > but --not sure whether the main thread will still have problems since it may > be waiting on the callback from DirectCOM.dll to go to the next code line?? > DirectCOM.dll is more or less a mere instantiation-helper - It can instantiate COM-Classes regfree in the same thread with its exportet GetInstance-Call - and it can do the same regfree instancing for Public Classes on their own (STA-) threads with the StartCOMObject-Call. The latter mode needs the already described "entry-function" (ThreadMain) within the Public Class - and offers then something like "low-level-threading" support. If you want an easier solution (simply moving your MainProject- Classes into Threads), then you should try an ActiveX-Exe, which should be more "straight-forward" (class-movement + adding async-decoupling code for the critical routines). The DirectCOM.dll threading-support requires some experience, it differs from the way you work with ActiveX- Exe-threading (e.g. you will have to deal with SafeArrays, to establish a shared-memory-area - use critical-sections etc.) Thought you are targeting a hardware-device - and want to move only a smaller part (the critical "realtime-code") into a thread. For such purposes this low-level-efforts would make sense - but not for something like your planned "sweeping blow". ;-) > Am I wasting my time with above or is an example (per your > kind offer) needed to work this out?? It would make sense, if you can identify clearly, what (smaller) part is currently causing some delays. For example I don't understand yet, what you mean with: "moving the tool after placement" and with "clockticks". If your solution suffers more with regards to "fast drawing" (no realtime-hardware-devices anywhere), then you should shade some more light on your problem. What codepart does not work "fluently" or fast enough for you ... in either case it would be good, if you could come up with a small example (if possible). To write such an example, you will have to identify the culprit first - try some profiling (using "Highres-Stopwatch- code" for example), to see which codeparts cause the largest delays - then try to isolate these codeparts in a separate (smaller) Demo-project - and ask again then, how to make such parts faster. Only if they cannot be implemented in a more speedy fashion, then it's time to think about threading. Olaf
|
Pages: 1 Prev: Do varous API calls work for non MS servers? Next: objFaxDocument.ConnectedSubmit error |