|
 |
On 08/08/2011 5:11 PM, Darren New wrote:
> On 8/8/2011 3:37, Orchid XP v8 wrote:
>> Oh, Google helps you find *millions* of hex editors. Which all cost
>> money.
>> And, from the look of their product websites, I suspect about 80% of them
>> are actually trojans.
>
> Fine. Here's a free one I've been carrying around since 1999 or so.
>
> Alternately, google for "freeware hex editor" and take your pick. :-)
> There's probably a bunch much nicer than this one, but since I need a
> hex editor about once every 3 years, this does for me.
>
I tried it (I trust you) and it behaves strangely under Win7 64 bit.
When I tried to resize the window I couldn't and the window "jumped" to
the far left of my screen. (I have the taskbar on the left and it went
below it.) Also when dragged it moved in steps. Strange!
--
Regards
Stephen
Post a reply to this message
|
|
|
|
>>> I also figured that the only reason that you can (say) embed an Excel
>>> spreadsheet in a Word document is because both products are produced
>>> by the same company.
>>
>> No no no. That's the whole *point* of COM. That's why there's a standard
>> interface definition language and such.
>
> See, I've always assumed that the glitering world of native Windows
> GUIs, IPC, DLLs, COM, etc. are all behind closed doors, accessible only
> to people who know how to write really low-level Windows code. And I've
> always assumed that the really /good/ stuff (like embedding one
> application inside another) is accessible only to Microsoft themselves.
> (Or anybody who pays really vast sums of money. People like Symantec.)
>
In reality, if you know what you are doing, and your own application
supports it properly, you can even link things within VBScript. The
problem being that "some" functionality gets seriously screwy, if its
not right, and MS' explanation on how to do it is... less than helpful.
I seem to remember that the example they had for doing it super-low
level, which you need for full functionality of "embeddable" objects,
like MS' own picture object, only showed how to instance a single
object, not handle them as a collection, or respond to clicks and other
effects on *all* of them at the same time. But, if you use IE, or even
their shell script system, these things are handled by code already set
up to do that sort of thing. Same if you are using a compiled language,
like the full VB (not the script).
All in all, while, in principle, you can do all sorts of fancy shit with
them, its still easier, unless you know how to do all the object
collection, respond to stuff instanced "after" the application is
running, i.e., late linked, without the application knowing before hand
what the interfaces are, etc., then your prior assumption is pretty
close to accurate. If all you are trying to do is say, link to an excel
document, to pull out a few known cells of data, to do other
calculations, but you don't have to actually "display" the page, its
damn simple. Otherwise, you end up pulling your hair out trying to find
example code of how to actually do that stuff, if your "intent" is to
access it using late binding, which, as I said, means that your program
doesn't already "know" how to handle some of the interfaces, but has to
set them up once running.
Mostly, the problems in that case all come down to "your" application
responding to messages from the control though. Which is why a spreed
sheet can be "read", but not displayed easily. The former requires
merely making a request, which is "immediately" returned, via the
request itself. Displaying it require telling it who the "parent window"
will be, then trying to get your application to "see" messages via the
Windows messaging system, which tell it where you clicked, what you
moved, etc. Your own application is effectively blind to these, without
some serious behind the scenes support, or unless you "prelinked" the
object, i.e., added it as part of the project, instead of creating the
connection later. This is especially obvious when you run the VBScript
engine in your own application, only to discover that it has
CreateObject, but that the, "Let clicks and things be handled for this
object", function is actually an IE feature, not something in the script
engine itself, so you have to somehow design one for yourself. The last
time I tried to figure that one out I gave up when the guy writing the
client that used scripting implemented the features directly anyway. lol
Post a reply to this message
|
|
fr> wrote: