[Jprogramming] Document Object Model

[Raul Miller]

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 <rauldmiller at 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
> <programming at 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 <rauldmiller at gmail.com> wrote:
> > >
> > > On Mon, Aug 26, 2019 at 6:27 PM 'Jim Russell' via Programming
> > > <programming at 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