Add DLL reference to project

Targets Windows
1

I was adding a DLL reference to my project by clicking Insert>ActiveX Component. And then selecting the reference from the references tab.

I’m wondering if this is the correct/most efficient way?

Here are some of the reasons that are making me question this approach:

  1. In case it makes a difference, I’m referencing the QuickBooks SDK ‘QBFC13.dll’
  2. After selecting this reference a module is added to my project containing about 90k lines of code. This makes debugging and building projects very slow.
  3. When the app is built (about 20 lines of code other than the module), it is 11.4mb with a library folder of 27.1mb. That’s a total of 38.5mb!!!
  4. Creating the exact same project in VS 2015 Community I simply add a reference. The project compiles and builds very fast. When built I get a single file executable that is 18.5kb!!!

I understand the way Xojo works with the library folder, rather than a single executable, but something doesn’t seem quite right.

2

[quote=316843:@Neil Burkholder]
4. Creating the exact same project in VS 2015 Community I simply add a reference. The project compiles and builds very fast. When built I get a single file executable that is 18.5kb!!![/quote]

You haven’t factor in the .NET 4.6 framework, the VC++ 2015 Runtime Library, and the QBFC13.dll, all of which are not in the 18.5kb file.

3

Use an older version of Xojo.
When they added support for ICU , the DLL overheads went up by 20Mb

https://forum.xojo.com/18071-2014r3-vs-2014r2-1-win32-file-size-icu-dlls/22#p233140

https://forum.xojo.com/18074-new-dlls-when-compiling-what-for

4

I was more concerned about the project becoming bogged down having the reference added in as a module. In a blank project with this reference added it takes 18 seconds to compile & launch the app. I takes another 7.5 seconds to quit the app and get back to coding. (25.56 seconds total). With out the reference it goes to less than 3 seconds total.

I guess I was wondering if there is a way of referencing the DLL without making an entire new module in my project.

5

If the DLL is correctly registered, then it is possible (not guaranteed) to try a declare to the methods within the DLL. Here is a helpful link with some of the declaring details and DLL loading rules: Declare statements and dll loading rules

6

Using this approach I would need to write a declare for every method I wanted to access?

7

Yes, the Xojo program would need a declare for every method to be accessed.

This is the issue, on one side of the spectrum the ActiveX components loads all of the methods to be accessible by Xojo. The other extreme is to only load the one or two methods by a declare, which lowers the size of the loaded program.

If the program will only need a few methods, then using declares likely has less overhead. If the program will be adding future functionality then it may be worth it to load the ActiveX component.

8

Thanks for the explanation. So now I have the choice of 150 declares or 90k lines of code.

I wonder how Excel VBA does it? It ‘compiles’ code on the fly in ‘no time’ making testing a breeze. How can it ‘compile’ and run so fast? I’m not trying to pick on Xojo, just curious.

9

For starters VBA (unlike VB6 and VB.Net) is not compiled… it is an interpeter

10

[quote=316881:@Neil Burkholder]I wonder how Excel VBA does it? It ‘compiles’ code on the fly in ‘no time’ making testing a breeze. How can it ‘compile’ and run so fast? I’m not trying to pick on Xojo, just curious.

[/quote]

VBA does not really compile. It creates P-Code, which is an interpreted language.
https://msdn.microsoft.com/en-us/library/aa240840(v=vs.60).aspx

Incidentally, that explains the huge difference in size you mention above.

The drawback of P-Code, is that it can be decompiled : https://github.com/bontchev/pcodedmp

11

Thanks for the explanations.

The same app running on Visual Studio (vb.net) takes about 3 second to compile and run. A full rebuild takes 3 seconds. A build after making minor changes takes 1 second. Hmm…

I was just hoping there was a way to get around that 25 second business…

BTW: I love Xojo, and am not trying to put it down. Just looking for a way to ease my pain. :wink:

12

The word compile for VB. Net community edition is incorrect. Translating basic to P-Code is at best half-way interpretation. That explains the speed, and is in no way comparable to Xojo compilation to native code. I had hoped you understood the implication of the explanations from Microsoft about that.

To quote that document :

And guess what ? When VB. Net is compiled to native code, it takes actually longer than Xojo.

I have no magic recipe to hasten compilation time, besides getting the fastest machine available. It is also true that the same project, run in Mac, takes a few seconds to compile. Not everybody can afford to get a Mac only for that, though. And still, the final mile must take place on a physical PC, let alone to address UI differences (fonts, labels baseline) and flicker.

13

Ah… Every time when I think I’ve circumvented the ‘You get what you pay for.’ philosophy… :wink:

Thanks for taking the time to explain.