thinBasic_GetTokenType ???

[Reinking]

Eros,

First of all, thanks kindly for your invite to this forum!

I am putting some finishing touches on a DAO library and I had a couple of questions:

1. Is there any way to decipher what a given parameter token variable type is?
If the script function call passes an array of n elements, can I tell whether
the array is of numeric or string type before I work with the array elements?

2. Is there a way for one user module to access the functionality of another? For instance, I could find a use for some Linked List routines without having to embed it again in the DAO lib.

3. Do you have a preference for user module symbol/equate naming conventions?


Regards,

John

[RobertoBianchi]

Hi John,


2. Is there a way for one user module to access the functionality of another?

Yes there is a way, but for now we make it only for the ThinBASIC_DT.DLL
This module exports the GetFuncAddress function that works like the WIN32 API GetProcAddress.
However GetFuncAddress is an undocumented function, we should still decide how to do.

Regards,
Roberto

[ErosOlmi]

Hi John,


First of all, thanks kindly for your invite to this forum! :) you are welcome. We are also preparing a static and dynamic library for users using MS C/C++ compilers


1. Is there any way to decipher what a given parameter token variable type is?
If the script function call passes an array of n elements, can I tell whether
the array is of numeric or string type before I work with the array elements?Currently not, sorry. But next release will have more function interface especially working on arrays. I will add a type checking but in next release.


2. Is there a way for one user module to access the functionality of another? For instance, I could find a use for some Linked List routines without having to embed it again in the DAO lib. As Roberto stated, yes there is a way but at the moment we consider it as reserved. There is an exported "GetFuncAddress" function in thinBasic.DT.DLL that will return a codeptr of the requested function passed as function ID. We think to implement it also in other modules but not in immediate future release. We are still testing it.


3. Do you have a preference for user module symbol/equate naming conventions?
We prefer to work in this way:
[list] regarding Function names, use a prefix equal to the module name followed by underscore, followed by your function name. For example, if you call your module JRDAO, use the following: JRDAO_Get... JRDAO_Set...
regarding equates, if the equate is a standard one under Windows programming, possibily use the same name following Power Basic WIN32API.INC declaration. Even if the same equate can be included in multiple modules loaded at the same time by the script, the first module declaring the equate will have higher priority and this will not create any problem if the value of the equate is the same all over multiple modules.

If the equate is a personalized one not a standard windows API one, use the same logic as for function names: %JRDAO_MyEquateNumber, $JRDAO_MyString or whatever.[/list:u]
If you agree on this way of working, I will put this into interface documentation. So thanks for asking, quite important question in order to keep development congruent.

Next thinBasic version should be ready by the end of the week. I'm having some GPF in module interface due to introduction of new functionalities into UI module. I hope to solve them quickly

Ciao
Eros

[Reinking]

Thanks for the information!

I'm implementing a GetRows method within the DAO library.
My first thought was to return a tab delimited string of fields per string array element. My second thought was to return a pointer to the record and let the Dll handle the storage. I'm still flip-flopping on the choice, but your responses show what I can and can't do at the moment.

Regards,
John

[ErosOlmi]

John,

I've introduced some new functionalities you may be interested.
You have to use thinBasic 1.0.8.2 in order to be able to use them.

Let me know if any problem.
Regards
Eros

[Reinking]

Eros,

I've been distracted on another project and unfortunately haven't had as much time to visit here lately. I will have a look!

Regards,

John

[ErosOlmi]

Take your time, John :)
It is one of the most precious thing we have.

Let me know if you need some exaplanation (no much documentation for new functions for the moment). Also consider we are changing return types of functions adding a more complete numeric type so there will be the following types (see below). If you have developed a module, you will just need to recompile with new thinCore.INC file.

I will let you know when.

Ciao
Eros



%thinBasic_ReturnNone = 0&
%thinBasic_ReturnNumber = 20&
%thinBasic_ReturnString = 30&

%thinBasic_ReturnCodeByte = 1&
%thinBasic_ReturnCodeInteger = 2&
%thinBasic_ReturnCodeWord = 3&
%thinBasic_ReturnCodeDWord = 4&
%thinBasic_ReturnCodeLong = 5&
%thinBasic_ReturnCodeQuad = 6&
%thinBasic_ReturnCodeSingle = 7&
%thinBasic_ReturnCodeDouble = 8&
%thinBasic_ReturnCodeCurrency = 9&
%thinBasic_ReturnCodeExt = 10&