Dim sBuffer (5) as byte, iShukaqiBH as long, as long I

For I=0 to 4
SBuffer (I)=0
Next I

IShukaqiBH=1

Call CopyMemory (sBuffer (1), iShukaqiBH, 2)

After the CopyMemory function performs, sBuffer (1) should be equal to 1, and now is the result of the 5, how be to return a responsibility excuse me,

CodePudding user response:

CopyMemory statement you have differences, it is suggested that include a ApiViewer tool

 Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long) 

CodePudding user response:

reference 1st floor Tiger_Zhao response:

CopyMemory statement you have differences, suggest install ApiViewer tool

 Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long) 

Thank you very much

1, when a statement is: Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any Source, As Any, ByVal Length As Long) when sBuffer (1) the result of 5 is wrong
2, when a statement is: Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long) when sBuffer (1) the results of 1 is the right

Excuse me, is this why, thank you, and why this statement a function can have more than one way, the result is not the same?

CodePudding user response:

CopyMemory is a special function, the prototype is made Void Pointers to adapt to any data structure,
Because of prototype of arbitrariness, VB parameter changes in a statement to the corresponding specific data structure,
Declaration and application do not match, if the light is wrong, or collapse,

Better to use good API, not only the basic knowledge, language is very profound,

CodePudding user response:

Thank Tiger_Zhao, but still want to bother to ask:

reference Tiger_Zhao reply: 3/f

CopyMemory is a special function, a prototype is made Void Pointers to adapt to any data structure,
Because of prototype of arbitrariness, VB parameter changes in a statement to the corresponding specific data structure,
Declaration and application do not match, if the light is wrong, or collapse,

Better to use good API, not only the basic knowledge, language is very profound,

Because the default is to use VB6 ByRef to pass parameters, so the
Statement 1: Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any Source, As Any, ByVal Length As Long)
Statement 2: Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)

Two declarations should actually be completely about ah, why the results will have two?

CodePudding user response:

I here two statements run the result is the same!

Major difference is the LibName statement 1 no suffix. DLL, may the system environment, a 64 - bit system?

CodePudding user response:

reference 5 floor Tiger_Zhao reply:

with me two statements run the result is the same!

Major difference is the LibName statement 1 no suffix. DLL, may the system environment, a 64 - bit system?

No, the 32-bit XP

CodePudding user response:

reference 5 floor Tiger_Zhao reply:

with me two statements run the result is the same!

Major difference is the LibName statement 1 no suffix. DLL, may the system environment, a 64 - bit system?

But what is the difference between this can?

CodePudding user response:

I there is no difference,
You must have the difference, what is the library call kernel32, virus? This plugin?

CodePudding user response:

refer to the eighth floor Tiger_Zhao response:

, I there is no difference between
You must have the difference, what is the library call kernel32, virus? This plugin?

Kernel32. DLL files, this is not a system call this COPYMEMORY function, not from kernel32. DLL call, but also to other files such as kernel32. CCC is called, impossible

CodePudding user response:

Just tried it once: (statement 1 plus ". DLL ")
Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (Destination As Any Source, As Any, ByVal Length As Long)

The result is result is 5

CodePudding user response:

Only to find problems from the environment,
Broken network,
Pass various antivirus, anti Trojan tool,
Pass various interface beautification, translation tools,
Close programs,
VB IDE cancel all the Add - in the loading,
New engineering testing,

CodePudding user response:

11 references Tiger_Zhao response:

can only find problems from the environment,
Broken network,
Pass various antivirus, anti Trojan tool,
Pass various interface beautification, translation tools,
Close programs,
VB IDE cancel all the Add - in the loading,
A new engineering testing,

Private Declare Sub CopyMemory Lib "kernel32. DLL" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Tried it once, the returned result is five, is also wrong, seems to be unstable, what is going on? CopyMemory, I can't use the

CodePudding user response:

Your system can't use is true!

CodePudding user response:

I tried on board, results: sBuffer (1) should be equal to 1, normal
My statement is on this
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pSrc pDst As Any, As Any, ByVal ByteLen As Long)

CodePudding user response:

The

reference 13 floor Tiger_Zhao reply:

your system can't use is true!

The latest research results are as follows:

The complete code is as follows:
The Public Function SendSKQ (ByVal iBiaohao As Long, ByVal ihuhao As an Integer, Optional ByVal iShukaqiBH=65535) As an Integer

Dim As SQL String, the rs As New ADODB. You
'when the value of 65535 iShukaqiBH iShukaqiBH extracted from the database
If iShukaqiBH=65535 Then
SQL="select a credit card machine number from yhxx where table number=" & amp; IBiaohao & amp; "And the household number=" & amp; nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull