ID:132894
 
Could browser controls (and popups) be made to support the special DM-based <IMG> tag properties (the iconstate, icondir etc attributes)? They're supported by seemingly every HTML-supporting control (output, grid, info) but not actually by the browser itself, funnily enough (oversight, perhaps?).
Just earlier I answered a newbie that could use this feature in browsers, and thought why shouldn't the browser have it as well, like the other controls. If not for misc usefulness, then it should be added at least for completeness' sake. =P If possible.
Agreed, but for now you can use a combination of browse_rsc and icon() to show icon_states and directions.
In response to Nadrew
Indeed (and that's what I answered the aforementioned newbie with). Of course, it would be nicer to be able to avoid that, as it creates additional overhead and resource files.

EDIT:A funny thing to mention though is that IIRC, you can't actually show specific frames using an /icon object, but you can with this <IMG> tag, when supported. :o Kinda an off-topic hint to extend /icon to be able to do this as well, though extending it in various ways is probably planned for a long time now as it is.
Kaioken wrote:
They're supported by seemingly every HTML-supporting control (output, grid, info) but not actually by the browser itself, funnily enough (oversight, perhaps?).

My guess is that it is indeed not an oversight, but rather that every other HTML supporting control is parsed by the client and only 'imitates' HTML support, whereas the browser control is actually an IE instance that is handed the HTML code without parsing it in advance.
Which is, where I guess browse_rsc comes into play.

I fully support the request though, even though I think it won't work as suggested, but more of through trickery with browse_rsc and supplying different automatically generated file links.
Kaioken wrote:
Could browser controls (and popups) be made to support the special DM-based <IMG> tag properties (the iconstate, icondir etc attributes)? They're supported by seemingly every HTML-supporting control (output, grid, info) but not actually by the browser itself, funnily enough (oversight, perhaps?).

The browser control is an actual browser (well, sort of--it's Internet Explorer) which does its own rendering of true HTML. Output and grid controls use DM's internal HTML parser to achieve HTML markup; they support only a subset of HTML, and grids even restrict it further by allowing only one style per cell. We have control over how these elements display images because the code that handles it is ours, and we have to manage those images ourselves just like we manage the HTML parsing. In the browser, all of this takes place within the guts of an ActiveX control we can only hook into. To my knowledge there are no hooks for handling img tags.

While I think this could potentially be doable through some convoluted JavaScript and some code on the DM end to handle certain requests from the browser, I suspect it would not produce satisfactory results in all cases and it would be very much a kludge.

Lummox JR
In response to Lummox JR
Yeah, I knew there was a fundamental difference between controls supporting HTML and the actual browser control which is more of a true IE instance. Still, I figure this should be feasible - as I recall, in pre-4.0 the browser control could display DMI files, which were then in a special format, meaning you've hooked into the image display process one way or another. Couldn't you use a similar approach to do this?

Lummox JR wrote:
The browser control is an actual browser (well, sort of--it's Internet Explorer)

Hehehehe....
In response to Kaioken
Kaioken wrote:
Yeah, I knew there was a fundamental difference between controls supporting HTML and the actual browser control which is more of a true IE instance. Still, I figure this should be feasible - as I recall, in pre-4.0 the browser control could display DMI files, which were then in a special format, meaning you've hooked into the image display process one way or another. Couldn't you use a similar approach to do this?

That was done by converting DMIs sent via browse_rsc() to PNG format in the cache. The IMG tag itself is not parsed, although as Lummox JR suggests there might be a way to manage that.
In response to Kaioken
Kaioken wrote:
Yeah, I knew there was a fundamental difference between controls supporting HTML and the actual browser control which is more of a true IE instance.

It's not merely more of a true IE instance; it is a true IE instance, and the others are not. Our code has some standard hooks it can use to talk to that instance, but Microsoft supplies none for tag parsing or special handling of images. What we can do is intercept link clicks, call JavaScript, fill in our own URL bar with info, etc.

Still, I figure this should be feasible - as I recall, in pre-4.0 the browser control could display DMI files, which were then in a special format, meaning you've hooked into the display process one way or another. Couldn't you use a similar approach to do this?

The reason the pre-4.0 browser could display .dmi files was that browse_rsc() was converting them to .png files silently. Doing this at the browser end is probably impossible, but if not then it's just a matter of catching navigation (to the image file) and then doing the conversion. Such a thing would give us no info about the attributes in the image tag though, which is what you would need to support our DM-custom attributes.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
It's not merely more of a true IE instance; it is a true IE instance

Yes, it's IE's actual engine embedded into the program, but it's not actually a true Internet Explorer (iexplore.exe) instance, as far as the term 'true' goes. That's what I was referring to. I thought since it's more of a bare IE embedded into a program, the program may have some control over it that would be useful here.

The reason the pre-4.0 browser could display .dmi files was that browse_rsc() was converting them to .png files silently.

Ah, that explains things. As mentioned, I thought there was actually some sort of leeway which was used to handle how the embedded browser displays the images.

Doing this at the browser end is probably impossible, [...]

Well, looks like it is. Too bad then.