C port of Type structure

[Scott Turchin]

Speaking of 3270 and HLLAPI and all that stuff, I thought I would port over the .H file while I had some idle time...

So I recall why I stopped, most of this is pretty easy....but, the NEAR and FAR confused me:

typedef struct tagHLLParams {
    BYTE    byAttribute;        /*  ATTRB or NOATTRB    */
    BYTE    byAutoReset;        /*  AUTORESET or NOAUTORESET    */
    BYTE    byConnectType;      /*  CONLOG or CONPHYS   */
    BYTE    byEAB;              /*  EAB or NOEAB    */
    char    cEscape;            /*  default '@' */
    BYTE    byPause;            /*  IPAUSE or FPAUSE    */
    BYTE    bySearchOrigin;     /*  SRCHALL or SRCHFROM */
    BYTE    bySearchDirection;  /*  SRCHFORWARD or SRCHBKWD */
    WORD    wTimeOut;           /*  0..64k          */
    BYTE    byTrace;            /*  TRON or TROFF   */
    BYTE    byWait;             /*  TWAIT, LWAIT, NWAIT */
    BYTE    byXlate;            /*  ASCII<->3270DC translation or not   */
    }       HLLPARAMS, NEAR * NPHLLPARAMS, FAR * LPHLLPARAMS;

What does this mean:
HLLPARAMS, NEAR * NPHLLPARAMS, FAR * LPHLLPARAMS;




------------------
Scott

[Tom Hanlin]

NEAR and FAR will be defined as nothing in a 32-bit C app for Windows. They only
exist for compatibility with 16-bit code. Ignore them if your code is 32-bit.

From a PB viewpoint, this C code sets up three types: HLLPARAMS, which is the UDT
(user-defined type) shown; plus NPHLLPARAMS and LPHLLPARAMS, which are types of
pointers to HLLPARAMS. In your PB code, you'd replace any references to NPHLLPARAMS
or LPHLLPARAMS with "HLLPARAMS PTR" or, if passed as a parameter, "BYREF xxx AS HLLPARAMS"
might be more convenient.

------------------
Tom Hanlin
PowerBASIC Staff

[Scott Turchin]

Thanks,
So that would be like
Type HLLPARAMS
ONE AS BYTE
End Type

Dim myHLL as HLLPARAMS


???

Seems pretty straightforward, and with that i should be able to get that entire HLLAPI ported over....

If anyone has a current copy of EXTRA! and wants to send me the HLLAPI.H from it I can port that over, mine is from 6.4

Scott

------------------
Scott

[Tom Hanlin]

Yep. The full structure translation goes:

TYPE HLLPARAMS
    byAttribute AS BYTE        '  ATTRB or NOATTRB
    byAutoReset AS BYTE        '  AUTORESET or NOAUTORESET
    byConnectType AS BYTE      '  CONLOG or CONPHYS
    byEAB AS BYTE              '  EAB or NOEAB
    cEscape AS STRING * 1      '  default "@"
    byPause AS BYTE            '  IPAUSE or FPAUSE
    bySearchOrigin AS BYTE     '  SRCHALL or SRCHFROM
    bySearchDirection AS BYTE  '  SRCHFORWARD or SRCHBKWD
    wTimeOut AS WORD           '  0..64k
    byTrace AS BYTE            '  TRON or TROFF
    byWait AS BYTE             '  TWAIT, LWAIT, NWAIT
    byXlate AS BYTE            '  ASCII<->3270DC translation or not
END TYPE

One "gotcha" to look out for in these cases is that C is case-sensitive, unlike PB.
You can get away with this in C:

HLLPARAMS hllparams; // define variable hllparams of type HLLPARAMS

This is not a good plan in PowerBASIC, even if you can get away with it!
If you see C code like this, change the name of the variable to avoid confusion.


------------------
Tom Hanlin
PowerBASIC Staff

[Scott Turchin]

Good catch, and this is going through a 3rd party DLL (EXTRA!'s EHLLAPI.DLL, IBM's also)....

So does mine have to be case sensitive? I'm slightly confused from your post....
When I dim it as HLLAPIPARAMS that should be sufficient? What about the sub pieces, ie wTimeOut ?

------------------
Scott

[Tom Hanlin]

The point is, C is case-sensitive, PowerBASIC isn't. So, if you find a C program where two symbol
names are distinguishable by having different case, you need to translate this in PB by using
entirely different names. For example, something like this:

HLLPARAMS hllparams;

might become something like this:

DIM hllparamsVBL AS HLLPARAMS

This is not an issue with the snippets of code that you've posted here. It's just a common
translation problem to keep in mind.

------------------
Tom Hanlin
PowerBASIC Staff