Hi Pablo, At work I managed to remote control Internet Explorer with Excel VBA like this... [1] http://www.automateexcel.com/vba/automate-internet-explorer and went looking for how similar might be achieved from Pharo. IIUC I discovered this would be done via Microsoft's Component Object Model, and then I bumped into your repo... [2] https://github.com/tesonep/pharo-com Could you advise the status and your plans for this? Since I see its only a few months old I've probably stumbled onto it prematurely, but I see no documentation or tests to discover how to use it. So I'll curious whether it makes something like [1] possible? And could you show how that would be done? cheers -ben P.S. For context, at work I automated IE since the intranet document management system (OpenText) does authentication via a javascript function in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument component. So I use IE to do the authentication and grab the raw XML from IE to then stuff it into MSXML.DOMDocument from which I pull the data I need. But I'd love to do it with Pharo instead (if I can get IT to white list it) cheers -ben
Hi Ben, first sorry for answering late, I have seen your mail before, but the tons of mails of Pharo got over it. I will tell you the state of what I have and what maybe you will need. But, before my plan is to improve this, but as with everything it is easier to push it if I have some users. - I have implemented a way of expressing FFI calls to COM objects, I have solved all the problems of the Vtable and the different types. So it is possible to create a wrapper for any of the COM objects. I have done so for the objects used in the "reflective" API of COM. - My idea is to use the reflective API to generate automatically the Pharo Wrappers to the objects. This is nice, but if you need to use some known objects you don't need all this transparency as using known instances can be easily implemented. - I have some examples using the IE COM object as it is a nice thing to use, and also it uses many different things in the API (properties, variant, optional parameters, etc). However, the support in the Variant type is not full yet. You can receive and send variant type values, but reading the different contents is not implemented (it has like 30 different payloads in the type, I have only the basics). I have to check what I have know, because I have been working a little more, but I have to put it in Github and organize it a little. Now it is working in Pharo 6 32Bits. My plan is to first migrate it to Pharo7 also (I think it should be straight forward) and then implement it for 64 bits (this part is possible that requires a big rewritting, as the API has some changes from 32 to 64 bits). In the next days I will try to make a couple of examples to show how to map a known class. I remember that the reflective part now can query the interface and perform dynamic calls but the way of interacting with it should be improved. I really will love to have somebody using it, so I will try to help you if you (or other) has a use case. Usually having a use case is easy to move a project. Cheers, Pablo On Mon, Oct 30, 2017 at 6:11 PM, Ben Coman <btc@openinworld.com> wrote:
Hi Pablo,
At work I managed to remote control Internet Explorer with Excel VBA like this... [1] http://www.automateexcel.com/vba/automate-internet-explorer
and went looking for how similar might be achieved from Pharo. IIUC I discovered this would be done via Microsoft's Component Object Model, and then I bumped into your repo... [2] https://github.com/tesonep/pharo-com
Could you advise the status and your plans for this? Since I see its only a few months old I've probably stumbled onto it prematurely, but I see no documentation or tests to discover how to use it. So I'll curious whether it makes something like [1] possible? And could you show how that would be done?
cheers -ben
P.S. For context, at work I automated IE since the intranet document management system (OpenText) does authentication via a javascript function in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument component. So I use IE to do the authentication and grab the raw XML from IE to then stuff it into MSXML.DOMDocument from which I pull the data I need.
But I'd love to do it with Pharo instead (if I can get IT to white list it)
cheers -ben
-- Pablo Tesone. tesonep@gmail.com
On Wed, Nov 1, 2017 at 6:08 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:
Hi Ben, first sorry for answering late, I have seen your mail before, but the tons of mails of Pharo got over it.
I will tell you the state of what I have and what maybe you will need. But, before my plan is to improve this, but as with everything it is easier to push it if I have some users.
- I have implemented a way of expressing FFI calls to COM objects, I have solved all the problems of the Vtable and the different types. So it is possible to create a wrapper for any of the COM objects. I have done so for the objects used in the "reflective" API of COM.
- My idea is to use the reflective API to generate automatically the Pharo Wrappers to the objects. This is nice, but if you need to use some known objects you don't need all this transparency as using known instances can be easily implemented.
So is you aim to help discover with something like Excel's "Tools > References" dialog...? * https://i.stack.imgur.com/J0rEr.jpg That would be super cool.
- I have some examples using the IE COM object as it is a nice thing to use, and also it uses many different things in the API (properties, variant, optional parameters, etc). However, the support in the Variant type is not full yet. You can receive and send variant type values, but reading the different contents is not implemented (it has like 30 different payloads in the type, I have only the basics).
I have to check what I have know, because I have been working a little more, but I have to put it in Github and organize it a little. Now it is working in Pharo 6 32Bits. My plan is to first migrate it to Pharo7 also (I think it should be straight forward) and then implement it for 64 bits (this part is possible that requires a big rewritting, as the API has some changes from 32 to 64 bits).
Sounds like a good plan.
In the next days I will try to make a couple of examples to show how to map a known class. I remember that the reflective part now can query the interface and perform dynamic calls but the way of interacting with it should be improved.
I really will love to have somebody using it, so I will try to help you if you (or other) has a use case. Usually having a use case is easy to move a project.
Next week when I'm back on site I'll paste here the exact VBA code I'd like to replicate. The business has OpenText running as its intranet document management system. * https://www.opentext.com/file_source/OpenText/en_US/PDF/opentext-product-ove... It useful some fancy Javascript stuff as part of its authentication process, so using XMLHttpRequest or WINHTTP from Excel don't seem to cut it - they don't seem to execute the Javascript, which is the same I expect from Pharo. So I use IE to get to the data page, something like this... * https://stackoverflow.com/questions/11805389/getting-data-from-html-source-i... * https://stackoverflow.com/questions/23299134/failproof-wait-for-ie-to-load and then with Excel I pass IE's "innerHTML" to MSXML to use XPath, but in Pharo I'd use available XPath libraries instead. cheers -ben
Cheers, Pablo
On Mon, Oct 30, 2017 at 6:11 PM, Ben Coman <btc@openinworld.com> wrote:
Hi Pablo,
At work I managed to remote control Internet Explorer with Excel VBA like this... [1] http://www.automateexcel.com/vba/automate-internet-explorer
and went looking for how similar might be achieved from Pharo. IIUC I discovered this would be done via Microsoft's Component Object Model, and then I bumped into your repo... [2] https://github.com/tesonep/pharo-com
Could you advise the status and your plans for this? Since I see its only a few months old I've probably stumbled onto it prematurely, but I see no documentation or tests to discover how to use it. So I'll curious whether it makes something like [1] possible? And could you show how that would be done?
cheers -ben
P.S. For context, at work I automated IE since the intranet document management system (OpenText) does authentication via a javascript function in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument component. So I use IE to do the authentication and grab the raw XML from IE to then stuff it into MSXML.DOMDocument from which I pull the data I need.
But I'd love to do it with Pharo instead (if I can get IT to white list it)
cheers -ben
-- Pablo Tesone. tesonep@gmail.com
Hi, I finally got some time to check Pablo's PharoCOM package closely. At first I had problems with simple things, like making Word visible with properyNamed:put: (it's frustrating when you see the app on the processes list but you cannot control it :-)) but then I found the reason - it was a tiny detail in Win32VariantBool>>#write:to:, and then - voila! Here's an example of opening Word for Windows, adding a blank document, typing some text and getting this text back to Pharo: Ole32Lib uniqueInstance initLibrary. wrd := COMDispatchInstance createInstanceByName: 'Word.Application'. wrd propertyNamed: 'Visible' put: true. docs := wrd propertyNamed: 'Documents'. docs dispatch: 'Add'. sel := wrd propertyNamed: 'Selection'. sel dispatch: 'TypeText' withArguments: {'Hello from Pharo!'}. sel dispatch: 'WholeStory' . Transcript show: (sel propertyNamed: 'Text'); cr. Another example is with Active Data Objects to get DB access: conn := COMDispatchInstance createInstanceByName: 'ADODB.Connection' . conn dispatch: 'Open' withArguments: { 'DSN=this; Uid=that; Pwd=theOther;' } . conn propertyNamed: 'State' . --> true! rst := (COMDispatchInstance createInstanceByName: 'ADODB.Recordset') . rst dispatch: 'Open' withArguments: { 'SomeTableName' . conn . 3 . 1 }. The last line raises an exception because not all of the data types that functions are reporting are implemented yet, as Pablo mentioned in his post. The package is really nicely prepared. The most impressive is it's reflective capability. My "proof of concept" work with DispHelper library that I mentioned in another forum topic was successful (I can get to the SQL Server :-)), however it's a dead-end regarding the reflection. I'm very interested in COM implementation since I found Pharo to be very useful as a tool, and since I work in "windowed" environment the COM interaction is crucial to me. I decided to spent my free evenings working on the project finalization. I'm not sure of how long will it take though :-) Pablo, I hope that I can count on your help regarding the questions about the overall architecture that you set. Is anybody else interested in this? Maybe we can join our efforts. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi, This is very nice to hear :) Iâm sure Pablo will help in his capabilities, we want to improve windows interaction as much as possible :) Esteban
On 25 Sep 2019, at 22:28, eftomi <tomaz.turk@ef.uni-lj.si> wrote:
Hi,
I finally got some time to check Pablo's PharoCOM package closely. At first I had problems with simple things, like making Word visible with properyNamed:put: (it's frustrating when you see the app on the processes list but you cannot control it :-)) but then I found the reason - it was a tiny detail in Win32VariantBool>>#write:to:, and then - voila!
Here's an example of opening Word for Windows, adding a blank document, typing some text and getting this text back to Pharo:
Ole32Lib uniqueInstance initLibrary. wrd := COMDispatchInstance createInstanceByName: 'Word.Application'. wrd propertyNamed: 'Visible' put: true.
docs := wrd propertyNamed: 'Documents'. docs dispatch: 'Add'.
sel := wrd propertyNamed: 'Selection'. sel dispatch: 'TypeText' withArguments: {'Hello from Pharo!'}.
sel dispatch: 'WholeStory' . Transcript show: (sel propertyNamed: 'Text'); cr.
Another example is with Active Data Objects to get DB access:
conn := COMDispatchInstance createInstanceByName: 'ADODB.Connection' . conn dispatch: 'Open' withArguments: { 'DSN=this; Uid=that; Pwd=theOther;' } . conn propertyNamed: 'State' . --> true! rst := (COMDispatchInstance createInstanceByName: 'ADODB.Recordset') . rst dispatch: 'Open' withArguments: { 'SomeTableName' . conn . 3 . 1 }.
The last line raises an exception because not all of the data types that functions are reporting are implemented yet, as Pablo mentioned in his post.
The package is really nicely prepared. The most impressive is it's reflective capability. My "proof of concept" work with DispHelper library that I mentioned in another forum topic was successful (I can get to the SQL Server :-)), however it's a dead-end regarding the reflection.
I'm very interested in COM implementation since I found Pharo to be very useful as a tool, and since I work in "windowed" environment the COM interaction is crucial to me. I decided to spent my free evenings working on the project finalization. I'm not sure of how long will it take though :-) Pablo, I hope that I can count on your help regarding the questions about the overall architecture that you set.
Is anybody else interested in this? Maybe we can join our efforts.
Best wishes, Tomaz
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I'm very interested in COM implementation since I found Pharo to be very useful as a tool, and since I work in "windowed" environment the COM interaction is crucial to me. I decided to spent my free evenings working on the project finalization. I'm not sure of how long will it take though :-) Pablo, I hope that I can count on your help regarding the questions about the overall architecture that you set.
Is anybody else interested in this? Maybe we can join our efforts. Have you checked out Dolphin Smalltalk's way of creating COM components? The Dolphin guys have a wizard to "automatically generate wrapper classes for all the interfaces defined in the type-library" (from the help file). Vince
On Wed, Sep 25, 2019 at 8:35 PM Vince Refiti < vince.refiti@trapezegroup.com.au> wrote:
Have you checked out Dolphin Smalltalk's way of creating COM components? The Dolphin guys have a wizard to "automatically generate wrapper classes for all the interfaces defined in the type-library" (from the help file).
I also was going to suggest checking Dolphin's approach as reference. They have the wizard to wrap visual (OCX) and non-visual components [1], and it works really well, I a past job we wrapped the whole Excel Object Model and a few other things to automate it from Smalltalk. Regards, [1] https://github.com/dolphinsmalltalk/Dolphin/tree/master/Core/Object%20Arts/D... Esteban A. Maringolo
Vince
Hi Tomaz, nice to hear you like the code you found. It is a prototype and it is still needing some work. Basically, I needed a use case to continue improving it. Also, historically there was a limitation with the callbacks coming from an external thread, but that should be fixed now with the new Threading-ffi plugin. So, it will be possible also to expose Pharo objects as COM objects. Of course, we should join efforts. Do you have any use case in mind to start working on? Thanks, Pablo On Wed, Sep 25, 2019 at 10:29 PM eftomi <tomaz.turk@ef.uni-lj.si> wrote:
Hi,
I finally got some time to check Pablo's PharoCOM package closely. At first I had problems with simple things, like making Word visible with properyNamed:put: (it's frustrating when you see the app on the processes list but you cannot control it :-)) but then I found the reason - it was a tiny detail in Win32VariantBool>>#write:to:, and then - voila!
Here's an example of opening Word for Windows, adding a blank document, typing some text and getting this text back to Pharo:
Ole32Lib uniqueInstance initLibrary. wrd := COMDispatchInstance createInstanceByName: 'Word.Application'. wrd propertyNamed: 'Visible' put: true.
docs := wrd propertyNamed: 'Documents'. docs dispatch: 'Add'.
sel := wrd propertyNamed: 'Selection'. sel dispatch: 'TypeText' withArguments: {'Hello from Pharo!'}.
sel dispatch: 'WholeStory' . Transcript show: (sel propertyNamed: 'Text'); cr.
Another example is with Active Data Objects to get DB access:
conn := COMDispatchInstance createInstanceByName: 'ADODB.Connection' . conn dispatch: 'Open' withArguments: { 'DSN=this; Uid=that; Pwd=theOther;' } . conn propertyNamed: 'State' . --> true! rst := (COMDispatchInstance createInstanceByName: 'ADODB.Recordset') . rst dispatch: 'Open' withArguments: { 'SomeTableName' . conn . 3 . 1 }.
The last line raises an exception because not all of the data types that functions are reporting are implemented yet, as Pablo mentioned in his post.
The package is really nicely prepared. The most impressive is it's reflective capability. My "proof of concept" work with DispHelper library that I mentioned in another forum topic was successful (I can get to the SQL Server :-)), however it's a dead-end regarding the reflection.
I'm very interested in COM implementation since I found Pharo to be very useful as a tool, and since I work in "windowed" environment the COM interaction is crucial to me. I decided to spent my free evenings working on the project finalization. I'm not sure of how long will it take though :-) Pablo, I hope that I can count on your help regarding the questions about the overall architecture that you set.
Is anybody else interested in this? Maybe we can join our efforts.
Best wishes, Tomaz
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- Pablo Tesone. tesonep@gmail.com
On Thu, 26 Sep 2019 at 05:18, tesonep@gmail.com <tesonep@gmail.com> wrote:
Do you have any use case in mind to start working on?
I can suggest something I did in the past (it's the idea behind PlantUML Gizmo). With Roassal, we can generate visualizations (PNG?) that go into a Word document. The source (which is a kind of DSL to produce an image, like PlantUML) can be in a playground. The problem is when you insert the image into word, you can't re-do it unless you have the source, which is in some Pharo image or Git repository... it's nicer to be able to keep the source inside your documentation (Word). So, a use-case would be to automate (with COM) the insertion of the visualization (a morph in the form of a GIF or PNG?) into the currently-open Word document. The Roassal source (DSL, from the playground) would be attached to the image as ALT_TEXT. That way, you could recover the source into Pharo later if/when you want to modify it after it's in your Word document. There would be a complementary function to recover the "selected" image/source from word back into Pharo. This is a rough description I know. I have made a plugin for Word (VSTO, VB.net) that does this using PlantUML.com and it works quite well. But you could easily imagine Pharo/Roassal as the DSL + image generator (it's a little more complex). Maybe not the most interesting use case, but it's something to test out the COM library. The source of the method to replace/insert an image in VB.NET I wrote is here [1] (the context is VSTO, so it's surely different in COM, but it might be useful to someone). Cris [1]: https://github.com/fuhrmanator/plantuml-word-add-in-vsto/blob/6f917e94779a1c...
Thanks, Pablo
On Wed, Sep 25, 2019 at 10:29 PM eftomi <tomaz.turk@ef.uni-lj.si> wrote:
Hi,
I finally got some time to check Pablo's PharoCOM package closely. At
first
I had problems with simple things, like making Word visible with properyNamed:put: (it's frustrating when you see the app on the processes list but you cannot control it :-)) but then I found the reason - it was a tiny detail in Win32VariantBool>>#write:to:, and then - voila!
Here's an example of opening Word for Windows, adding a blank document, typing some text and getting this text back to Pharo:
Ole32Lib uniqueInstance initLibrary. wrd := COMDispatchInstance createInstanceByName: 'Word.Application'. wrd propertyNamed: 'Visible' put: true.
docs := wrd propertyNamed: 'Documents'. docs dispatch: 'Add'.
sel := wrd propertyNamed: 'Selection'. sel dispatch: 'TypeText' withArguments: {'Hello from Pharo!'}.
sel dispatch: 'WholeStory' . Transcript show: (sel propertyNamed: 'Text'); cr.
Another example is with Active Data Objects to get DB access:
conn := COMDispatchInstance createInstanceByName: 'ADODB.Connection' . conn dispatch: 'Open' withArguments: { 'DSN=this; Uid=that; Pwd=theOther;' } . conn propertyNamed: 'State' . --> true! rst := (COMDispatchInstance createInstanceByName: 'ADODB.Recordset') . rst dispatch: 'Open' withArguments: { 'SomeTableName' . conn . 3 . 1 }.
The last line raises an exception because not all of the data types that functions are reporting are implemented yet, as Pablo mentioned in his post.
The package is really nicely prepared. The most impressive is it's reflective capability. My "proof of concept" work with DispHelper library that I mentioned in another forum topic was successful (I can get to the SQL Server :-)), however it's a dead-end regarding the reflection.
I'm very interested in COM implementation since I found Pharo to be very useful as a tool, and since I work in "windowed" environment the COM interaction is crucial to me. I decided to spent my free evenings working on the project finalization. I'm not sure of how long will it take though :-) Pablo, I hope that I can count on your help regarding the questions about the overall architecture that you set.
Is anybody else interested in this? Maybe we can join our efforts.
Best wishes, Tomaz
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- Pablo Tesone. tesonep@gmail.com
-- Christopher Fuhrman, P.Eng., PhD *Professeur au Département de génie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supérieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'Université du Québec*
Hi, > Do you have any use case in mind to start working on? As a professor at business school I have various use cases, like developing business web applications where you cannot do anything without DB access (e. g. Oracle, SQL Server), where COM & ADO could be used. Besides, I could present to the students various cases of middleware connectivity & integration, up to the REST API, along with the COM(+). I'm interested also in workflow/business processes that another Pharo group is working on, but that's a different story :-) And this would go together with the display of a true OO language and dev environment. As a researcher I'm using tools to grab, process, analyze and save the data in various forms and tools, where Pharo could be the middle man - the orchestrator. To do that on the most powerful level in Windows you need COM. To cut it short, my needs are not really complicated, since I need COM only to "command" other applications and to get some basic/elementary data back. For that, as I see, the PharoCOM prototype just needs additional data types (at least the most used ones) to properly marshall the property and method calls and arguments. Today I studied the world of VT_VARIANTs, VT_BYREFs, VT_BSTRs and other strange types in COM world :-) If anybody has a good e-book on this I'd be most grateful :-) >From all the responses today I see that our desires go further, like: - a possibility to generate wrapper classes as interfaces to outside servers (Vince, Esteban M.) - expose Pharo objects as COM objects (Pablo) - OLE/COM implementation on a real case (Cris) Pablo, I hope that these explanations are interesting to you. If we are going to develop the functionalities together, then you have to give me/us some directions and rules (github etc). And, patience please, Smalltalk is my like tenth language, and I'm just starting more seriously with it :-) For the development, is it preferable to use Pharo 8? Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Pablo, Before doing Invoke() in COMDispatchInstance>>#dispatch, the array of parameters for a COM method call is currently prepared under the assumption that the parameter types reported by COM for a particular method should be used directly, i. e. if a COM method reports VT_BSTR as its parameter type, then the parameter value is prepared as VT_BSTR. This is implemented in COMMethod>>#fillArguments:byTypeOn:. The fact is that this is not always a one-to-one association. For instance, if a method reports VT_VARIANT as a parameter type, other variant types could also be send, not just VT_VARIANT, but VT_BSTR, VT_I4, ..., too. It's the responsibility of the server to do the conversion and report a problem if the conversion is not possible (for instance, converting a string '42' to integer 42 works). Many COM objects implementations report "vague" parameter types, like the VT_VARIANT that I mentioned, VT_USERDEFINED etc, and the fact is that the server on the other side is usually quite forgiving. So, the actual parameter value and its type that is prepared before the dispatch could depend also from the data on the client side - my point is that if the COM server is really expecting an integer number but is reporting VT_VARIANT, you can send to it the string '42' as VT_BSTR or integer 42 as VT_I4 or integer 42 as VT_I2 etc. My question is whether you had any plans to implement this behaviour, and if yes, how? Of course, one thing is sending parameter values as a client, but if we think about exposing Pharo classes through COM this should be carefully planned for. A mapping between Pharo variant type classes and VT classes is now prepared in TypeMapping class variable of Win32Variant. Maybe we also need a mapping between Pharo/ST types from Magnitude, String and other class families to COM VT types. Anyway, I'm progressing well and various calls to ADODB's objects are working - of course as a prototype :-) Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (7)
-
Ben Coman -
Christopher Fuhrman -
eftomi -
Esteban Lorenzano -
Esteban Maringolo -
tesonep＠gmail.com -
Vince Refiti