Nope; dll’s are one of the lead items in my vast storehouse of ignorance. Thanks!
> On Aug 27, 2019, at 11:45 AM, Raul Miller <rauldmil...@gmail.com> wrote: > > Oh, and http://www.dependencywalker.com/ can be useful for having an > understanding of the dlls underneath a wrapper dll. > > But you probably already knew that. > > Thanks, > > -- > Raul > >> On Tue, Aug 27, 2019 at 11:43 AM Raul Miller <rauldmil...@gmail.com> wrote: >> >> System.Windows.Forms.dll is another likely possibility, since that's >> what exports the HtmlDocument class for windows. >> >> Good luck, >> >> -- >> Raul >> >> On Mon, Aug 26, 2019 at 7:29 PM 'Jim Russell' via Programming >> <programm...@jsoftware.com> wrote: >>> >>> Yes, very much. As I recall, a single DOM handled all web pages; a class of >>> objects containing collections of headings, buttons, fields, etc. For any >>> particular page, a bit of inspection of the collection’s attributes might >>> be required to orient/validate the composition, but, save for major >>> changes, the object could be programmatically manipulated. But I may have >>> forgotten everything; I’ll look into your .dll approach. Thanks very much. >>> >>>> On Aug 26, 2019, at 7:08 PM, Raul Miller <rauldmil...@gmail.com> wrote: >>>> >>>> On Mon, Aug 26, 2019 at 6:27 PM 'Jim Russell' via Programming >>>> <programm...@jsoftware.com> wrote: >>>>> I think the VBA and Java document object model are similar, if not >>>>> the same. With it, a program can access a web page and all of its >>>>> attributes (get text, change fields, click buttons, etc.) >>>>> as an object, rather than resorting to screen scraping. I would >>>>> assume that a J implementation would access the page hierarchy using >>>>> the j-unique approach of locale class names and __numeric__ objects. >>>> >>>> Well, first off: conceptually, if there's a windows dll that offers >>>> what you want, you can use it from within J: >>>> https://www.jsoftware.com/help/user/call_procedure.htm >>>> >>>> So, for example, you could use Windows.Data.Xml.Dom.dll from inside J, >>>> if that suited your needs. >>>> >>>> That said, creating a J object to shadow each object in a DOM system >>>> would run into a whole batch of memory management and synchronization >>>> glitches. There's at least two different (conflicting) memory >>>> management philosophies already in the windows DOM implementations, >>>> and adding J objects would introduce a third. This could be done, but >>>> it would be slow and it would require a deep understanding of all >>>> three systems in some contexts. Personally, I would avoid that. >>>> >>>> But, it could make sense to create one top-level J class to represent >>>> the DOM interface, with an instance for each DOM document you were >>>> working with. This would isolate the use of that interface from the >>>> rest of the system. Here, you'd probably be working with numeric >>>> representations of objects -- they would just be external DOM objects >>>> and not native J objects. >>>> >>>> (You would still have to deal with some of those memory management >>>> issues, but hopefully the direct use of the interface will take some >>>> of the mystery out of them.) >>>> >>>> I hope this helps, >>>> >>>> -- >>>> Raul >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
