I've made a program in VB 3.0 in which I use the functions
GetPrivateProfileString and WritePrivateProfileString for
reading and writing of a ini-file.
It's works okay in VB 3.0.
Now I've installed VB 4.0 32-bit and tried to import my program in it.
When I run the program I get the message: BAD CALLING DLL CONVENTION
and the program aborts!
What is wrong??? Must I use the 16-bit version of VB 4.0 or must I
change the functions for reading the ini-file?
Hope somebody can help me,
Thanks a lot!
Pieter Peters
Pieter Peters <Pie...@go.don.com> wrote in article
<5c4lvo$1...@ns1.nl.cis.philips.com>...
> Question:
>
> I've made a program in VB 3.0 in which I use the functions
> GetPrivateProfileString and WritePrivateProfileString for
> reading and writing of a ini-file.
> It's works okay in VB 3.0.
>
> Now I've installed VB 4.0 32-bit and tried to import my program in it.
> When I run the program I get the message: BAD CALLING DLL CONVENTION
> and the program aborts!
>
> What is wrong??? Must I use the 16-bit version of VB 4.0 or must I
> change the functions for reading the ini-file?
I believe all of the INTS have changed to LONGS in the 32 bit version. BAD
CALLING DLL CONVENTION usually means that at least one of the variables
defined in the DECLARE is not what the function in the DLL is looking
for.... Check the API text viewer or simply try changing all the INTS to
longs in the DECLARE.
Tim
Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long
The API viewer that comes with VB4.0 can also be used to get the
correct declarations for most API calls.
RichardF
On Wed, 22 Jan 1997 18:12:31 GMT, Pie...@go.don.com (Pieter Peters)
wrote:
>Question:
>
>I've made a program in VB 3.0 in which I use the functions
>GetPrivateProfileString and WritePrivateProfileString for
>reading and writing of a ini-file.
>It's works okay in VB 3.0.
>
>Now I've installed VB 4.0 32-bit and tried to import my program in it.
>When I run the program I get the message: BAD CALLING DLL CONVENTION
>and the program aborts!
>
>What is wrong??? Must I use the 16-bit version of VB 4.0 or must I
>change the functions for reading the ini-file?
>
>Question:
>
>I've made a program in VB 3.0 in which I use the functions
>GetPrivateProfileString and WritePrivateProfileString for
>reading and writing of a ini-file.
>It's works okay in VB 3.0.
>
>Now I've installed VB 4.0 32-bit and tried to import my program in it.
>When I run the program I get the message: BAD CALLING DLL CONVENTION
>and the program aborts!
>
VB 4.0 provides GetSetting and SaveSetting. If you compile the program
as 16 bit, it uses ini files, in 32 bit it stores the settings in the
register.
Phew!
Sid/
>Question:
>
>I've made a program in VB 3.0 in which I use the functions
>GetPrivateProfileString and WritePrivateProfileString for
>reading and writing of a ini-file.
>It's works okay in VB 3.0.
>
>Now I've installed VB 4.0 32-bit and tried to import my program in it.
>When I run the program I get the message: BAD CALLING DLL CONVENTION
>and the program aborts!
>
>What is wrong??? Must I use the 16-bit version of VB 4.0 or must I
>change the functions for reading the ini-file?
>
>Hope somebody can help me,
>Thanks a lot!
>
>Pieter Peters
>
The declarations have changed. Try this...
Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long
Declare Function WritePrivateProfileString Lib "kernel32" Alias
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String)
As Long
[snip]
>
>The API viewer that comes with VB4.0 can also be used to get the
>correct declarations for most API calls.
>
>RichardF
>
...but that would require the programmer to read! We don't have time
for such trivial activities; we have more important things to do!
Jeff
The reason for this error is that the VB4-32 is designed to use the
Windows 95 registry instead of the ini files used under Windows 3.1x
As far as I know, the only way around this is to use a 16-bit version
of VB, as you suggested. Frustrating, isn't it. :-)
Simon.
Despite what others have said Get/WriteProfileString work fine in 32bit
VB40. Change your declarations to the following
Private Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long
Private Declare Function WritePrivateProfileString Lib "kernel32" Alias
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As
Long
Verify that all of the arguments you pass are the correct size.
BEM
>The reason for this error is that the VB4-32 is designed to use the
>Windows 95 registry instead of the ini files used under Windows 3.1x
>As far as I know, the only way around this is to use a 16-bit version
>of VB, as you suggested. Frustrating, isn't it. :-)
Wrong. VB4, both 16 and 32 bit, is quite capable of using ini files
via the API calls. While true on a Win95 system the VB4-32
Get/SaveSettings basic routines write to the registry, the APIs can
still be used as before. In fact, this is often preferable.
The key is to assure that the declare statements for the 16bit APIs
are correctly converted to the Win95 32-bit statements. The API
Viewer can provide these.
Public Declare Function WritePrivateProfileString Lib "kernel32"
Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As
String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal
lpFileName As String) As Long
Public Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString
As String, ByVal nSize As Long, ByVal lpFileName As String) As Long
--------------
Randy Birch, MVP
Visual Basic
randy...@msn.com
Moderator, Fidonet Visual Basic Programmer's Conference
Visit VBnet at http://home.sprynet.com/sprynet/rasanen/
> >What is wrong??? Must I use the 16-bit version of VB 4.0 or must I
> >change the functions for reading the ini-file?
> As far as I know, the only way around this is to use a 16-bit version
> of VB, as you suggested. Frustrating, isn't it. :-)
>
> Simon.
Not so! There are 32-bit versions of these two functions. They work
identically to the ones you were using in VB3. You just need to change your
function declaration to the 32-bit version. I much prefer using an .ini to
the registry.
Try these:
Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long
Declare Function WritePrivateProfileString Lib "kernel32" Alias
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As
Long
Neal
m...@apex.net
>> [snip]
>
> ...but that would require the programmer to read! We don't have time
> for such trivial activities; we have more important things to do!
>
> Jeff
TRIVIAL?!?! Get your head screwed on straight, Jeffy. Reading is one
of the most fundamental activities of programming. The manual, for
instance. Or the help file. Or the VB Books Online. Etc. Etc. Etc.
If we didn't read, none of us would be programming. Instead, we would
all be posting questions here when it would take less time to look it
up in the manual(s) or to do a search in the help file.
-- Boneman
Kim Dobranski
ki...@cdi.net
--------------------------------------------------------
Commerce Direct International - CDI
http://www.cdi.net
Boneman <m...@mysite.org> wrote in article
<3307990c...@news.cyberg8t.com>...