We started using Visual DLL on a very large VB project (>90 .frms & >80
.bas) recently since we started hitting VB's 64K limitations. By putting
into DLLs parts of our functionality, we have been able to decrease the size
of the Global Name Table. That is, private functions are really private to
that DLL now and do not get counted in the Global Name Table.
A few things to note about Visual DLL in no particular order:
- You can only pass to Visual DLL functions, VB basic data types and user
defined types. That is, you cannot pass forms or controls as parameters.
- If using msgblast.vbx, while a DLL function is running which sends a
message to the message blaster, the message blaster cannot call another
function in that same DLL. In essence a callback?
- It's better to start thinking of Visual DLL during the design phase instead
of in the middle of development. That is, think of which functionality you
can put into DLLs before doing actual development. This will make the design
of that DLL much better.
- In terms of reuse, Visual DLL has great potential.
- Be aware of lstrcpy when returning strings from functions. That is, you
need to use them.
That's all I can think of at the moment. Other than that, Simply Solutions
has good tech support. The reason I'm not saying stellar is because the only
way to get support is via e-mail. When you're in crunch mode, sometimes,
it's kind of nice to be getting support from a person on the other end. They
do respond to your queries and give you solid answers.
Rory
--
Rory M. dela Paz | "In the time of chimpanzees
rd...@ctp.com | I was a monkey"
(617) 374-8521 | - Beck
----------------------------------------------------------------------------