Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 78

Thread: Excel COM question...

  1. #11
    Hello Gerald and John,

    In fact, msvbvm60.dll (VB6 runtime virtual machine) is a system32 library on all MS Windows platforms from XP upwards. This makes it possible to be used more or less directly rather than include COM as a native language layer (a.k.a. module, addon, extension, whatever).

    The following is a quick and dirty implementation of a thin (125 VB6 code lines) wrapper around msvbvm60.dll usable in any procedural language without resorting to COM Variant structures. I'm not including the VB6 code here because it can't be compiled without a very special VB6 IDE setup that allows for native (not ActiveX!) DLL compilation.

    The zip contains equivalent thinBasic and FBSL scripts as well as a precompiled FBSL executable. The VB6COM.dll module should be placed alongside the scripts and EXE for them to run successfully. Please note that the DLL is not complete; it implements only such functionality as is needed for these particular scripts and it shouldn't be used for further experimentation. The both scripts mimic thinBasic's classic Excel_RandomCellFill.tBasic sample but do not use TB's COM extension.

    Due to the extreme simplicity of VB6COM.dll, it is functional under Win XP only.
    Attached Images Attached Images
    Attached Files Attached Files
    Mike
    (3.6GHz i5 Core Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, x64 Windows 7 Ultimate Sp1)

  2. #12
    I did a quick search of the thinBasic forum for COM Excel examples and found this thread. I'm not sure if anything has been done since in this area but maybe Petr or Eros will give us an update.

    Funny. Who would of guessed Script BASIC would be the one ending up doing COM right.
    ScriptBasic Project Manager
    Project Site
    support@scriptbasic.org

  3. #13
    Super Moderator Petr Schreiber's Avatar
    Join Date
    Aug 2005
    Location
    Brno - Czech Republic
    Posts
    7,128
    Rep Power
    732
    Gerald,

    the reason for current level of COM implementation state is that it is not used much in ThinBASIC. You are the first one to ask for it in... well, years

    If you are owner of PB compiler, I can guide you through process how to create wrapper module, which would allow OOP like usage in ThinBASIC.
    Eros put lot of effort in OOP modules, and the way they are designed allows wrapping COM object to TB in straightforward manner.

    If we could put together neatly working Excel interface module this way, whole community would benefit.

    Are you familiar with Git?


    Petr
    Learn 3D graphics with ThinBASIC, learn TBGL!
    Windows 10 64bit - Intel Core i5-3350P @ 3.1GHz - 16 GB RAM - NVIDIA GeForce GTX 1050 Ti 4GB

  4. #14
    Quote Originally Posted by John Spikowski View Post
    Funny. Who would of guessed Script BASIC would be the one ending up doing COM right.
    A very arrogant statement, don't you think? In my opinion, VB, VBA and VBS are the languages that have their COM access interfaces implemented in the most comfortable way. All other implementations (TB, FBSL and SB included - can't say anything about PB though) are nowhere near them as far as user friendliness and intuitive intelligibility go.
    Mike
    (3.6GHz i5 Core Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, x64 Windows 7 Ultimate Sp1)

  5. #15
    I think Dave surprised all of us with his Script BASIC COM interface. Why should I not be proud of that effort? Gerald has confirmed that the SB example is more like what he is use to. I think most BASIC users could give a rats ass about low level COM and just want use it with as little pain as possible.
    Last edited by John Spikowski; 19-07-2014 at 23:26.
    ScriptBasic Project Manager
    Project Site
    support@scriptbasic.org

  6. #16
    John,

    I'm very happy that you're so proud of Dave's achievements against the former total lack of that feature in the language. But if you have a closer look at FBSL and TB scripts that I've posted, you will see that both of them implement the exact same low-level syntax that Dave uses in his ActiveX plug-in for SB. And that was done in 45 minutes and in 125 lines of VB6 code and it is valid for two languages at once, and it's gonna be valid for SB too had you cared to model your own SB script after the ones that I provided.

    Still all of it is very, very far away from the beauty of MS's simple dot notation used consistently throughout their COM aware products.

    There's also another point to it. ActiveX is a technology that requires COM components to be registered in the HKEY_CLASSES_ROOT branch of Windows registry. Most of us can easily live with it because we are usually the only owners of our machinery and we all have Administrator (i.e. "root") privileges on our computers. But an ordinary user with limited access rights won't be able to install and use your smart ActiveX interface for SB because their UAC watchdog won't let them do it. VisualBasic is able to register its COM components in HKEY_CLASSES_ROOT only.

    In contrast to this, my VB6COM.dll is a module written in VB6 and compiled in the VB6 IDE as a native dynamic load library. It doesn't require registration yet it interacts with msvbvm60.dll which is a 100% COM-based and must-register product. VB6 application context initialization is automatic under usual ActiveX conditions (provided your UAC allows it, hehe) but it becomes a PITA if you want to overcome this restriction. Yet my quick and dirty sample allows you to enjoy VB6 COM support in its glory in almost any language regardless of your root privileges. But again, only through this barbaric low-level syntactic nightmare.

    My real message was "Look how easy COM functionality really is. Don't waste your time re-inventing the wheel. Concentrate yourselves on a decent COM access syntax instead."

    On a side note, such a low level COM interface has been available and fully functional in FBSL for decades. But I was always feeling uneasy about its printf()-style syntax. It's alien to BASIC in all its implementations be it TB, or SB, or FBSL.

    Or VB6COM.dll, for that matter.
    Last edited by mike lobanovsky; 20-07-2014 at 02:06.
    Mike
    (3.6GHz i5 Core Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, x64 Windows 7 Ultimate Sp1)

  7. #17
    I'm very happy that you're so proud of Dave's achievements against the former total lack of that feature in the language.
    That is untrue. Charles has had low level COM support in the Script BASIC DLLC extension module for awhile now. What Dave brings to the table is a way to use VB6 custom forms and components within SB. He has created a SB ActiveX scripting control that can be easy used with other COM supporting languages. The IDE/DEbugger was a long time coming requirement if SB was to be taken seriously. And to top it off he has demonstarted .NET component use with the COM extension module. Lets all give Dave a hand. With the many contributions from the talented guys that helped Script BASIC get were it is today is a testimony that open source works.
    Last edited by John Spikowski; 20-07-2014 at 01:27.
    ScriptBasic Project Manager
    Project Site
    support@scriptbasic.org

  8. #18
    John,

    When I'm saying "I'm happy", "I'm happy" is what I mean. There's no teasing in my words, neither evident nor latent.

    Of what you said in your message, the only thing that's really appealing to me is the incremental debugger. This is what I should have in FBSL too but still don't.

    As for "open source works", well, it does, sorta. Sometimes. But that's not its indispensable feature. Open source relies heavily on philanthropy of generous individuals, such as Charles or Dave, to name a few, and communal projects are almost always doomed to enthropy and oblivion in their absence.

    But that's another story that doesn't relate well to the "thinBasic (the language)" or "Modules specific issues" boards of this forum.
    Mike
    (3.6GHz i5 Core Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, x64 Windows 7 Ultimate Sp1)

  9. #19
    Hello all,

    Thank you very much! However, it was not my intention to start a competition or feud.

    I find that when using Excel macros, the VBA structure is fairly clear. My problem I translating that into how TB would want to see it. I had the same problem with PB in the beginning ... just trying to figure out what was required. I have made progress with PB, but there are still a lot of things I haven't figured out yet. That is not a problem with either language ... it IS a problem with MY understanding of what is required.

    It is true that SB looked more familiar to me than TB ... but I was comparing that to PB (and of course, even they are not the same). It's just that I'm having difficulty figuring out what TB expects to see as a "methodName", for example. I've tried a lot of the combinations that I have pulled from VBA, but I get a lot of error messages and a lot of them say that some TB equate is not available. Again, it is my lack of understanding that is at fault. I'll admit that a few examples would probably go a long way to enhancing my understanding (just have to get my foot in the door). ;-)

    Petr, that sounds interesting, however I'm not sure that what little I have done so far would do anyone very much good ... but I would be interested in the technique you mentioned. One other thing though ... wouldn't it be against PB's policy to encapsulated their functionality into something for different language (perhaps with the exception of a DLL)? I'm not clear on this subject, and as I recall, TB had some issues with this in the past. Anyway, I would interested learning how this sort of thing can be done.

    Tomorrow I'll see if I can get a couple of the things I have done working in SB so that I can demonstrate where I am headed with this. Is it okay for me to post either SB or PB code here for such an illustration? (wanted to ask first).

    I'll try to look into that VB6 DLL as well, thanks Mike!

    Thank you !
    Jerry
    Last edited by Gerald Sutherland; 20-07-2014 at 05:04.

  10. #20
    Quote Originally Posted by Petr Schreiber View Post
    Gerald,

    the reason for current level of COM implementation state is that it is not used much in ThinBASIC. You are the first one to ask for it in... well, years

    If you are owner of PB compiler, I can guide you through process how to create wrapper module, which would allow OOP like usage in ThinBASIC.
    Eros put lot of effort in OOP modules, and the way they are designed allows wrapping COM object to TB in straightforward manner.

    If we could put together neatly working Excel interface module this way, whole community would benefit.

    Are you familiar with Git?


    Petr
    With the seemingly demise of PowerBASIC, one would think Jose Roca would have shown some interest in making thinBasic more COM aware. I asked him to help out with the Script BASIC COM effort working with Dave but never got a reply. He seems partially active on his forum answering questions and updating his includes. There is a lot of idle talent that could be put to good use if the current mentality wasn't to program in BASIC you must create a variation of the language first.
    ScriptBasic Project Manager
    Project Site
    support@scriptbasic.org

Page 2 of 8 FirstFirst 1234 ... LastLast

Similar Threads

  1. Question of the day ;)
    By Petr Schreiber in forum thinBasic General
    Replies: 8
    Last Post: 23-08-2010, 19:58
  2. gdi question
    By Lionheart008 in forum UI (User Interface)
    Replies: 6
    Last Post: 07-12-2009, 19:31
  3. Replies: 3
    Last Post: 31-03-2009, 23:16
  4. MS Excel as 3D engine :D
    By ErosOlmi in forum Development
    Replies: 3
    Last Post: 13-03-2008, 01:09
  5. Equivalent VBA Excel code
    By marcel in forum COM
    Replies: 12
    Last Post: 08-11-2007, 16:18

Members who have read this thread: 0

There are no members to list at the moment.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •