[Martenlist] external structure access problem

[Adrian Wirz]

Thanks for your fast reply Jack!

Can the mailing list be configured so that pictures remain in the 
messages? That would be really helpful if one describes a problem with 
specific code that could be included as a picture!

The 4DOpen library I'm using still uses Pascal strings. But I know that 
Marten strings are C-type strings and that I have to convert them when 
setting external fields.

What is the external set operation actually doing in case of a 
character array? Anything useful? Could it be "adapted" to work as in 
Prograph? I ask because I have a lot of "legacy code from Prograph" 
which sets lots of external fields in external structures. Having the 
same behaviour as in Prograph would make coding easier and the code 
more readable than the workaround that you suggested. But thank you for 
the valuable hint, especially the external "address get" which is very 
interesting! Your hint helps me a lot and will allow me to get on with 
my code immediately.
--> I just clicked the data terminal of the "address get" ( 
 >&StationName> ) while stepping through the code and Marten immediately 
crashed! I just wanted to have a look at the returned pointer. Maybe a 
bug?

> Oddly enough, you can just use a "regular" external-get to access the 
> array, but you will need to write a function to extract pascal 
> strings, as Marten only knows how to deal with c strings.
Does that mean that if I put a C string into an external field using 
your hint I can then retrieve it by using a "regular" external-get to 
get that string back again? I implemented your hint which works great 
but when I access the field with a "regular" external-get I receive 
something like "unsigned char at 0234A0B0" ! I then have to issue another 
get-text to really get the C string.
--> Wouldn't it be more convenient and also more readable  if one could 
simply use "regular" external-set and get operations to put strings 
into external character arrays?

While debugging my code which works with lots of external structures I 
missed one feature very much (which Prograph had):
It is being able to have a HEX Dump of an external block in an external 
value window. This is very important for me since I must often check 
the contents of a block for specific data (which is very easy looking 
at a hex dump). When I open the external value window I get something 
like IDRec at 02348460 and when I choose Hex from the View As popup menu 
nothing happens.
--> I would very very very much appreciate this if you could implement 
this funcionality! Please!

One excellent feature of Marten that I love much is being able to save 
changes made while stepping through the code. So it is possible to keep 
all modifications made to the program until  a crash happens 
eventually. Prograph did NOT have this feature and many times I lost 
lots of bug corrections when Prograph crashed.

Thanks for all the good work!

Kind regards              Adrian

++++++++++++++++++++++++++++++++++++
+   Adrian D. Wirz, SCOUT Systems
+   Software Development and Systems Support
+   CH-5615 Fahrwangen
+   Tel +41(0)56/670'10'51
++++++++++++++++++++++++++++++++++++

---> "Nothing is impossible for the man who doesn't have to do it 
himself."
--->  Anonymous   ;-)


On 29.09.2006, at 22:29 Uhr, Jack Small wrote:

> Adrian,
>
> On Sep 29, 2006, at 9:08 AM, Adrian Wirz wrote:
>
>> I have finally succeeded in integrating a dynamic library into a 
>> framework. After some tests it seems to run pretty well (finally). 
>> The main problem was linking the dynamic library with a non-standard 
>> name in Xcode 1.5 which seems to be rather reluctant to find such a 
>> library when linking.
>
> Well, truly, congratulations!  That's a huge accomplishment right 
> there!
>
>> Now there are a few problems regarding access to external structures. 
>> Here is one:
>>
>> The following declaration run through the C tool yields the 
>> subsequent result:
>>
>> typedef unsigned char 	st32[32];
>> typedef struct IDRec {
>> 					 st32		StationName;
>> 					 st32		UserName;
>> 					 st32		UserPass;
>> 					 st32		TaskName;
>> 					 Boolean 	isapi;
>> 					 Boolean 	unused;
>> 				} IDRec;
>>
>> After running through the C tool:
>>
>> VPL_ExtField _IDRec_6 = { 
>> "unused",129,1,kUnsignedType,"NULL",0,0,"unsigned char",NULL};
>> VPL_ExtField _IDRec_5 = { 
>> "isapi",128,1,kUnsignedType,"NULL",0,0,"unsigned char",&_IDRec_6};
>> VPL_ExtField _IDRec_4 = { "TaskName",96,32,kPointerType,"unsigned 
>> char",0,1,NULL,&_IDRec_5};
>> VPL_ExtField _IDRec_3 = { "UserPass",64,32,kPointerType,"unsigned 
>> char",0,1,NULL,&_IDRec_4};
>> VPL_ExtField _IDRec_2 = { "UserName",32,32,kPointerType,"unsigned 
>> char",0,1,NULL,&_IDRec_3};
>> VPL_ExtField _IDRec_1 = { "StationName",0,32,kPointerType,"unsigned 
>> char",0,1,NULL,&_IDRec_2};
>> VPL_ExtStructure _IDRec_S = {"IDRec",&_IDRec_1};
>>
>> I cannot access the string fields in IDRec from within Marten (build 
>> 056.00g006) with the following code:
>>
>> IDRec external object
>>          °
>>          |   "MyMac String"
>>          |         °
>>          |        /
>>          °       °
>>        <StationName<
>>              °
>>              |
>>              °
>>        >StationName>
>>           °     °
>>
>> The code is executed alright but when I retrieve the fields again 
>> they contain nothing or garbage. So I asked myself whether the 
>> computed type (kPointerType) of the fields is correct? Or is the way 
>> I access the fields not correct?
>
> Well, first of all, that's an excellent text representation.  I'm not 
> sure why the mailing list is sending out plain-text only messages, but 
> it is very annoying.
>
> Technically, the fields are character arrays, which is why they are 
> given pointer types.  However, these are not pointers to strings 
> (which would have a size of 4) which is why Marten gets confused.
>
> My first question is:  Are these pascal strings (with a length byte 
> first) or are they c strings (with a terminating zero)?  Typically, 
> char arrays of this type are pascal strings, but that depends on the 
> implementation.
>
> I would solve this using a little known technique for external gets.  
> Instead of using an external set ( <StationName< ), I would use an 
> "address get" to get a pointer to the character array ( >&StationName> 
> ) then use put-integer/text to poke in the correct values.
>
> Here is an example that will poke in a pascal string:
>
> <pastedGraphic.png>

> Oddly enough, you can just use a "regular" external-get to access the 
> array, but you will need to write a function to extract pascal 
> strings, as Marten only knows how to deal with c strings.
>
>> I'd be very happy about some help here. Thanks.
>
> I hope this helps!  If not let me know and we will find some way!  
> You're really close!
>
> More later,
> Jack
>