Cpp 2 PB translation but understanding
Re: Cpp 2 PB translation but understanding
I think You have to look to see the problem with Longs, Quads and Assertion
Re: Cpp 2 PB translation but understanding
uh?
You re right : I have to look big headaches this end of week !
You re right : I have to look big headaches this end of week !
Re: Cpp 2 PB translation but understanding
Thank You for reply.
In the attachment the Luxand Face SDK.
The strange thing is that sample (C++, C#, Java, VB.Net and VB) codes are working. Means Dll engine is not buggy. But in PureBasic it malfunctions but shouldn't.
Up to FSDK_FeedFrame is OK. After is obscure.
In the attachment the Luxand Face SDK.
The strange thing is that sample (C++, C#, Java, VB.Net and VB) codes are working. Means Dll engine is not buggy. But in PureBasic it malfunctions but shouldn't.
Up to FSDK_FeedFrame is OK. After is obscure.
Re: Cpp 2 PB translation but understanding
I think the main problem is the choice of types you took.
I can see :
#fsdNGn="fsdk_62_64.dll"
It is 64 bits version.
All your outputs have 32 bits :
PrototypeC.l
dot l = dot long = 32 bits (on pb)
Change it to "dot I" (uppercase i) to have 64 bits :
PrototypeC.I
(replace function on edit menu in IDE)
I can see :
#fsdNGn="fsdk_62_64.dll"
It is 64 bits version.
All your outputs have 32 bits :
PrototypeC.l
dot l = dot long = 32 bits (on pb)
Change it to "dot I" (uppercase i) to have 64 bits :
PrototypeC.I
(replace function on edit menu in IDE)
Re: Cpp 2 PB translation but understanding
Thanx, let me try and write result
Re: Cpp 2 PB translation but understanding
Hi Olliv,
According to Your recommendation I fixed problems in includefile, changed PrototypeC.l to PrototypeC.I
But did You success obtaining FaceCount, IDs and FacePosition in Tracker? I couldn't...
According to Your recommendation I fixed problems in includefile, changed PrototypeC.l to PrototypeC.I
But did You success obtaining FaceCount, IDs and FacePosition in Tracker? I couldn't...
Re: Cpp 2 PB translation but understanding
If I have availability with test, I ll do a test.
Re: Cpp 2 PB translation but understanding
Hope next release will solve, lets wait for next pb release
Re: Cpp 2 PB translation but understanding
Also... I go and read what new about such a bug I do not imagine from compiler actually unless I looped a message in a bug report...
Re: Cpp 2 PB translation but understanding
No! I did not find bug report message... So, I will get your source code containing listing of PrototypeC, and check each type of variable helped by the on-line doc...
Re: Cpp 2 PB translation but understanding
But... What did happen about this listing of PrototypeC ?
Well, it's not a problem... I just need the on-line doc...
Well, it's not a problem... I just need the on-line doc...
Re: Cpp 2 PB translation but understanding
Let's see this macro named 'external'.
It just removes a little bit of typing and of boring tests.
Could you test it, inserting the DLL file name and inserting key code string?
I typed a list of displayed value I want you to report here as result.
It just removes a little bit of typing and of boring tests.
Could you test it, inserting the DLL file name and inserting key code string?
I typed a list of displayed value I want you to report here as result.
Code: Select all
;****************************************************************************************************************************************************************************************
Macro Quote
"
EndMacro
Macro External(arg, arg0 =, arg1 =, arg2 =, arg3 =, arg4 =, arg5 =, arg6 =)
CompilerIf Quote#arg1#Quote <> ""
CompilerIf Quote#arg2#Quote <> ""
CompilerIf Quote#arg3#Quote <> ""
CompilerIf Quote#arg4#Quote <> ""
CompilerIf Quote#arg5#Quote <> ""
CompilerIf Quote#arg6#Quote <> ""
PrototypeC arg(arg0, arg1, arg2, arg3, arg4, arg5, arg6)
CompilerElse
PrototypeC arg(arg0, arg1, arg2, arg3, arg4, arg5)
CompilerEndIf
CompilerElse
PrototypeC arg(arg0, arg1, arg2, arg3, arg4)
CompilerEndIf
CompilerElse
PrototypeC arg(arg0, arg1, arg2, arg3)
CompilerEndIf
CompilerElse
PrototypeC arg(arg0, arg1, arg2)
CompilerEndIf
CompilerElse
PrototypeC arg(arg0, arg1)
CompilerEndIf
CompilerElse
PrototypeC arg(arg0)
CompilerEndIf
Define arg.arg = GetFunction(Library, Quote#FSDK_#arg#Quote)
EndMacro
Define.S DllName = "" ; Please insert dll file immediate string /!\
Define.S License = "" ; Please insert dll key immediate string /!\
Define.I Library = OpenLibrary(#PB_Any, DllName)
If Library
External(ActivateLibrary, License.P-Unicode)
;External(ActivateLibrary, License.P-ASCII)
Debug #PB_Compiler_Unicode
Debug DllName
Debug Library
Debug ActivateLibrary
Debug ActivateLibrary(License)
EndIf
Re: Cpp 2 PB translation but understanding
Ups... I removed ' = 0 ' which cancels the load test.
Without DLL, I just get empty values :Normally, you get more informations than just some zeros and spaces.
I wait your report...
Without DLL, I just get empty values :
Code: Select all
1
0
0
I wait your report...
Re: Cpp 2 PB translation but understanding
Hi,
what is the benefit of using macroway?
what is the benefit of using macroway?
Re: Cpp 2 PB translation but understanding
The economy of syntax.
Here, I allow you
to declare a function simply.
what enables this below
Sure that 'invoking' just one time a macro does not seem to be useful. But this subject is not static. We are moving around an executing access error between a external library and pb.
This presents many questions and this forces us to make points of view to respond to the problem.
1) A macro allows you to get just one-line solution.
2) Here, we want to handle any calls of external functions.
3) You observe two problems :
3a) Root language assertion failure.
3b) Bad values resulting from one of the executing extern functions.
Technically, a function, wherever it comes from, it is ever the exchange of local variables.
Each variable has a defined type.
Each type has one, or many, format(s).
In the way of the 'string' type, there is 'sub-formats' too.
Sure that a global macro is root of headaches. That is the reason you can see two macros in this subject. And I think a third and a fourth macro should be required : this depends of the values you can report.
Here, I allow you
to declare a function simply.
Code: Select all
External(myFunction, arg1, arg2)
Code: Select all
; call of function
myFunction(2, 3)
This presents many questions and this forces us to make points of view to respond to the problem.
1) A macro allows you to get just one-line solution.
2) Here, we want to handle any calls of external functions.
3) You observe two problems :
3a) Root language assertion failure.
3b) Bad values resulting from one of the executing extern functions.
Technically, a function, wherever it comes from, it is ever the exchange of local variables.
Each variable has a defined type.
Each type has one, or many, format(s).
In the way of the 'string' type, there is 'sub-formats' too.
Sure that a global macro is root of headaches. That is the reason you can see two macros in this subject. And I think a third and a fourth macro should be required : this depends of the values you can report.