Even if you use no VB code and only use Win32 API calls, it still needs the vb modules . It seems as though vb''s equivalent of a main() function is implemented in the vb modules
Nekosion - that''s why I said you''d have to subclass, you create your own Sub Main. I''ve heard it can be done (I used to use VB a lot but have moved over to C/C++ now since VB is a crappy language to make games with) but it''s a bit pointless.
Nekosion - that''s why I said you''d have to subclass, you create your own Sub Main. I''ve heard it can be done (I used to use VB a lot but have moved over to C/C++ now since VB is a crappy language to make games with) but it''s a bit pointless.
Harry.
Yeah, it can be done. There is even a place on the net: Common Control Replacement Project, (don''t know the URL) that makes coded versions of common controls using api and stuff so you can cut down on the size of your app even more.
BeS It''s Da BOMB Baby!!! . o O ~ A little nonsense now and then, is relished by the wisest men ~ O o . -- Willy Wonka
BeSIt's Da BOMB Baby!!!. o O ~ A little nonsense now and then,is relished by the wisest men~ O o .-- Willy Wonka
I know you can create your own Sub Main() in VB, but it doesn''t act in the same respect that Main() does in C. What it allows you to do in VB, is manage the load process of your application. By default VB expects you to use a form as your start point, that form is immediately loaded and shown upon running the application.
Using Sub Main() takes a step back and gives you control prior to any forms being loaded (which you then have to manually load and show). For instance if you have two seperate forms in your project, you can load one or the other or both, at runtime by sticking code into Sub Main(), which is the first procedure executed (pending you defined and selected it as the start point in the IDE, over the traditional form selection). You can also use Sub Main() to create a formless application. However I''m not sure if a formless app needs MSVBSM60.DLL, I''ll have to test that out.
I don''t have much experience with sub-classing, but I understand the concept. I''ll have to look into that Common Control Replacement Project, could be helpful in the future if I get stuck using VB again for some reason. Just to quickly comment on VB being a crappy game development language, well truthfully it doesn''t have the range, speed, or platform independancy you''d really want out of a language for all possible game types. But in certain cases it has it''s pluses. Not that I''m defending VB or anything, but consider simple puzzle games, card games, or something along the lines of Shadow Gate. Sure they could all be done way better in C, but for the casual game programmer VB is a quick and easy way to get results.
BTW VC++ applications do not require the MSVCRT.dll if you statically link the library into the executable. MSVCRT.dll is only needed if you link dynamically. If your code is being distributed on a machine that already has the MSVCRT.dll you might as well go dynamic. One reason not to go dynamic is if a customer has versioning requirements yet you want to use the latest libraries. Statically include the libraries and that avoids the problem.