Acmlm's Board - I2 Archive - Programming - And you thought VB was bad for adding unneeded stuff to files?
| User | Post |
neotransotaku
Posts: 1718/4016 |
if you set the breakpoint in the DLL and then look at the memory address you get in, you can see what you are passing in and how to fix it (that is how I solved my string returning from C to VB problem)
Make a VB program use the DLL and then run the DLL by using that VB program when VC++ asks for a program that will use the DLL |
HyperLamer
Posts: 2105/8210 |
Originally posted by neotransotaku
he function definition in VB needs to pass the string "ByVal", this creates a char* from C's point of view.
 It worked, but printed the wrong number! I got "000000000000004C" when I should get "1122334455667788"...
And I would do the string manipulation in VB, but it won't really work. The DLL contains a set of functions for working with 64-bit variables. Since VB doesn't support them, the DLL handles all access and storage of them. (I guess I could make a function in VB that grabs the variables and prints them... But C's is faster and more flexible.  )
Originally posted by sloat
You're complaining about a 36kb file when VB uses a 2 Meg runtime?
Ironic, yes, but at least you only need one copy of said runtime. Plus it comes with XP, no downloading to do. (But yes, VB's runtimes do suck. HEY BILL! MAKE ONE THAT COMPILES TO ASM ALREADY!  )
About VB's unicode-ness, I think it copies the string to another buffer, in non-unicode format, unless you tell it not to. (Since few API functions will accept unicode strings.) |
neotransotaku
Posts: 1707/4016 |
VB is in unicode weird, because when I passed strings to C, that wasn't the case (I read the memory that came in for the string and it wasn't unicode...)
so, yeah, that is another thing look out for. To enable unicode building in C, replace _MBCS (or something that looks like that) with _UNICODE. Also, if you are working with _UNICODE or _MBCS, make sure you use the "t_" macros. MSDN should have something on them. |
sloat
Posts: 15/85 |
You're complaining about a 36kb file when VB uses a 2 Meg runtime?
There are other optimizations that you could do that will bring it down further, but if you want to use the C Runtime functions, then 36kb is about as small as it will get.
VB stores strings in Unicode and C depends on your build configuration. If you switch to Unicode for C, the functions will switch automatically afaik, but strings have to be prefixed with an L...like so:
MessageBox(0, L "Something", L "Something else", 0);
also char is still a regular char...it's not unicode. i forget what the type is and i think you have to enable it in the build settings.
or you could use the conversion strings WideCharToMultiByte and MultiByteToWideChar. WideChar means unicode btw, and multibyte is regular. |
neotransotaku
Posts: 1703/4016 |
ah, yes..using C to do your string manipulation from VB...nasty stuff...
anyways, VB and C store strings differently. There is a site that explains what is going on but I don't recall where to find in Google.
Anyways, I believe you need to do the following to get what you want
1) the function definition in VB needs to pass the string "ByVal", this creates a char* from C's point of view. (Otherwise, passing ByRef creates a char**)
2) pass in a string of length 17 from VB for where the result of the sprintf will go. this gives C enough space to write what you need and for VB to see the changes easily.
in your case, the string you are formatting always has constant size. this is why i ask you to pass in a string of length 17. Otherwise, you need to provide a place for VB to read the formatted string. Because C arrays are fixed in size, you need to allocate the space before hand (either in VB or C -- better to do it in VB since if you do it in C, you have memory leaks not unless you write a "free" function for VB)
also, VB strings have 2 extra bytes. before where the string starts to hold the size of the string. If you still have problems, I'll see if I can dig up the page that explains how to do string manipulation in C from VB.
in my experience, you should only do something like this if you are using C to store strings, using C to do string manipulation that VB will use is nasty but doable... |
HyperLamer
Posts: 2092/8210 |
Oh, pfft. I thought I had it set to Release Build...  Got down to 36K, but that still seems big. Still has a lot of empty space, unneeded error messages, days of the week, what looks like a LOT of code, and several API function declares.
Imagine that, it actually worked. But one function's not working right...
//Print the variable into a string
__declspec(dllexport) void _stdcall Cstr64(unsigned int varid, char* string, char* format, int size)
{
sprintf(string,format,GetHighHalf64(var[varid]),GetLowHalf64(var[varid]));
}
Calling this from main() when compiled as an EXE works, but calling it from VB (in both cases with '%08X%08X' as the format) doesn't apply the proper formatting to it. It just comes out as %08X%08X, rather than a number. |
Dish
Posts: 194/596 |
All I can say is look at your compiler options. You're right, there's no reason for any of what you mentioned. If this is VC++, you should be doing a "release" build and not a debug build (but still mess with the release build options to optimize it the way you want... sometimes it still includes debugging stuff, don't ask me why)
Dcahrakos: you should be able to use any compiler. I know gcc/gpp has options to build a dll. |
Sokarhacd
Posts: 660/1757 |
is it only possible to make a DLL for use in VC++ or can you use mingw, or any other free compiler? |
neotransotaku
Posts: 1700/4016 |
and you compiled in release build?
but anyways, for VB to read a VC++ DLL, have you done the stuff as shown here:
Visual Basic with DLLs |
HyperLamer
Posts: 2090/8210 |
I just compiled an 8KB source file into a DLL in VC++. Guess how big it is.
Nope.
Still too low.
Give up? 140KB!  (And to make matters worse, that's after removing the very big debugging strings. Guess how big it is with them? EXACT SAME SIZE. ) All it does is math. Why the hell are there like names of countries and languages in it? What good does 32K of the byte 0xCC do? How do I get all this junk out of my file?
[edit] Oh, and here's the best part: VB can't find the functions in it! How do I do that anyway? I did it once but I can't seem to find how. |
|
