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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> wrote: > > > > > > On Mon, Aug 26, 2019 at 6:27 PM 'Jim Russell' via Programming > > > <[email protected]> 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
