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
