Mr.Mouse wrote:I can see you clearly have a good way of thinking! You must do this stuff for some time now! Professionally maybe? What do you do for a living?
Coding and Electrical Engineering, I like to think i have good logical skills as well as good problem solving skills. Unfortunately, having developed these skills, leaves me lacking in creativity skills(art, drawing, design). My last job was solely creating development tools for the developers
.
Mr.Mouse wrote:These Istreams would have to be declared in MultiEx Commander as well then. How would this work out? Suppose I wish to open an archive (say .MyArch) and retrieve a resource from it (say MyFile.res), how would the commander procede?
It does HAVE to have it, only if it plans to use these functions. The way I had it planed out is, that I'll have One activex Plugin tool that you call, and it will handle the calls to all the other plugins for you. I have since found out VB cannot call functions out of normal dlls
, at least dynamically. Statically, YES, but dynamically, no, you have to use a com/activex object. So I'll write an activex plugin manager, so that you can import that into. And Since, multiex commander won't call those functions (it will use the original methods (send filename)), it doesn't need to define IStream, but is available if we do plan to change multiex commander later. But your "scan" program would have to define it, look at the MS web site i posted, maybe you can gleam info on it from there. I'm DEFINATELY not familiar with importing Interfaces into VB.
This IStream GUID is {0000000C-0000-0000-C000-000000000046} if you need it. Fortunately Delphi already has it defined in the ActiveX module. I like to think of Delphi as "VB with power" as the syntax is as easy and nice as VB, but you get the power of C++. Just a personal preference, but unfortunately not a lot of companies use it, because its not marketed like MS markets tools.
One of my projects is a new compiler plugin for Delphi, to add some features I would like it to have. MACROs also some new function types "constinconstout" and "compiletime". constinconstout tells the compiler that if constants are passed in, constants are passed out, and if the compiler sees that function with all constants, it executes it at compile time, and returns it as a constant, which if it can, can be further parsed down. Also, allowing for PIC (Position Independant Code) so that when you import a unit and you only use one function, you only import that function(and anything it uses). Also a couple of nuisances that piss me off when coding
.
I really want macros to do something like this
Code: Select all
{$IFDEF DEBUGMEMORY}
{$MACRO AllocateMem(s) Track_GetMem(s, __FILE__, __LINE__)};
{$ELSE}
{$MACRO AllocateMem(s) GetMem(s)}
{$ENDIF}
this way a programmer can type AllocateMem and whereever it does that the compiler will insert the filename and the line number. That way when you, say debug your memory, and there was a place you didn't free the memory, you can find out the File and line number that you created the memory, but didn't free it.
You know, simple things like that, that people need. Right now, you'd have to pass the filename and line number everytime you did it, which is kind of a pain for a programmer.
[EDIT]what i'd really like to do is. is make the activex plugin manager, export functions as well as an activex control, this way, you can use either.[/EDIT]