I'm not sure what you're trying to do - but; For example; ufget is a call to get data from Uniface into a 3gl like C. ufput is a call to put data from a 3gl to Uniface. Further information can be found in the CHM file under APIs: 3GL Functions. In other words, the Uniface 3gl library / functions exists to facilitate transfer of data to/from a 3gl, not to be called from Uniface itself. I hope this helps. Regards, Knut

uGetHwnd works within a uniface form the way i suggest. I though was the same for other operations.   Regards, Sergio

fearandir said uGetHwnd works within a uniface form the way i suggest. I though was the same for other operations.

Hi Segio, Calling uGetHwnd from Proc certainly makes sense, since there's no equivalent Proc function or statement for this. But why would you like to call ufget? There are easier ways to get the data from a field of a component (i.e. addressing it directly from Proc).

It, however, should be possible to create a C call-out signature that calls ufget. I see in your post that you've defined the BUFFER parameter only as IN. That is not correct. The field value will be returned in this parameter and it therefore needs to be defined as INOUT. And what's the max length of the parameter? You need to make sure that the MAX parameter (with the size of the buffer pointed to by BUFFER) is set to a value that is not bigger than the size of the BUFFER parameter (to be on the safe side use a smaller value). And I'm not sure if anyone already has created a signature for YRTL with other functions. I (so far) was only interested in uGetHwnd and never really bothered to look at the other functions. But there's no ready-made C Call-Out signature I'm aware of. I hope this helps. Regards, Daniel

diseli said

fearandir said uGetHwnd works within a uniface form the way i suggest. I though was the same for other operations.

But why would you like to call ufget? There are easier ways to get the data from a field of a component (i.e. addressing it directly from Proc).

Was just an example. I was just experimenting what information is returned for each function. Originally, a team member was mumbling about a way to get the widget type of a field.   Greetings, Sergio

fearandir said Originally, a team member was mumbling about a way to get the widget type of a field.

Thanks for clarifying this. The only way (AFAIK) to get the widget type of a field is by using the Open Widget Interface (OWI). If you check the header file owi.h (in \\uniface\\3gl\\include) then you should find a function called oGetWidget(). By passing the name of a field the function should return (amongst other things) the name of the logical and physical widget associated with that field. The mentioned function cannot be called directly from (e.g.) a C Call-Out signature. So you would need to create a module (written in e.g. C/C++) that will do the call. Unfortunately the OWI is not really well documented. It would be interesting to know for what you would need the widget type of a field. Hope this helps. Regards, Daniel

diseli said

fearandir said Originally, a team member was mumbling about a way to get the widget type of a field.

Thanks for clarifying this. The only way (AFAIK) to get the widget type of a field is by using the Open Widget Interface (OWI). If you check the header file owi.h (in \\uniface\\3gl\\include) then you should find a function called oGetWidget(). By passing the name of a field the function should return (amongst other things) the name of the logical and physical widget associated with that field. The mentioned function cannot be called directly from (e.g.) a C Call-Out signature. So you would need to create a module (written in e.g. C/C++) that will do the call. Unfortunately the OWI is not really well documented. It would be interesting to know for what you would need the widget type of a field. Hope this helps. Regards, Daniel  

Hi daniel. As far as i know my partner is working in the modernization of a legacy application. This includes a global proc to adjust  to modern screen resolutions. When you resize a field if it contains an image, it could look bad so before resizing fields he want to know dinamically what is gonna resize and define specific treatments. We are talking about 900 forms  . So, an automatized process based of design rules is almost mandatory if he want to keep sane. regards, Sergio

Hi Sergio, Thanks for the additional info. This probably will not work in all cases, but you could check the datatype of a field (using $fieldinfo("FLD1.ENT1", "DATATYPE")). In case the field contains an image then the datatype should also be "Image". Another approach could be to extract the required info from the repository and store it in (e.g.) a table or file. I admit that this will create some additional overhead. E.g. you have to make sure that the data with the widget information is always up-to-date. Just an idea. Hope this helps. Regards, Daniel