diseli said In case this not make a difference either, then you have to check if the value sent to the browser is the same as the one received back from the browser. You should be able to do this by checking $webinfo("DATA") in the Set State (STST) and the Get State (GTST) trigger of your DSP.

In my case the DATA channel is empty Regards Claudio

diseli said

Claudio said YW My doubt is, as the field is null, the value of the placeholder can cause the problem. Regards, Claudio  

I'm not sure I can follow you here. What kind of problem could the placeholder cause? Are we still talking about the -259 error of webload? It would be a bit odd (IMO) to use a placeholder with a NED field. Thanks, Daniel  

Completely agree. In my case the placeholder is automatically showed, I don't know if it can depend on widget settings. I have not said it before, because I do not think that affects the WebLoad...just a suspect. Regards, Claudio

Claudio said YW My doubt is, as the field is null, the value of the placeholder can cause the problem. Regards, Claudio  

I'm not sure I can follow you here. What kind of problem could the placeholder cause? Are we still talking about the -259 error of webload? It would be a bit odd (IMO) to use a placeholder with a NED field. Thanks, Daniel

diseli said

Claudio said Take a look here: https://fiddle.sencha.com/#fiddle/9o7&view/editor Notice the input text of the "name" field on the right. Regards, Claudio  

Thanks for clarifying this. You could use the HTML5 placeholder attribute for this (works for HTML input and textarea fields). The mentioned attribute can easily be set (e.g.) by Proc code:

putitem/id $properties(FLD1.ENT1), "html:placeholder", "My Empty Text" In case you only want this for the active occurrence then you should use $fieldproperties. Hope this helps. Regards, Daniel  

YW My doubt is, as the field is null, the value of the placeholder can cause the problem. Regards, Claudio

Claudio said Take a look here: https://fiddle.sencha.com/#fiddle/9o7&view/editor Notice the input text of the "name" field on the right. Regards, Claudio  

Thanks for clarifying this. You could use the HTML5 placeholder attribute for this (works for HTML input and textarea fields). The mentioned attribute can easily be set (e.g.) by Proc code:

putitem/id $properties(FLD1.ENT1), "html:placeholder", "My Empty Text" In case you only want this for the active occurrence then you should use $fieldproperties. Hope this helps. Regards, Daniel

diseli said

Claudio said Thanks Daniel, no problem. Last question: there is a "empty text" value for the widget when field is empty? Thanks again, and again Claudio  

 Thanks Claudio. And you are welcome. I, however, don't exactly understand what you mean by "there is a "empty text" value for the widget when field is empty". In case a field is empty then you should see in the JSON stream for the DSP a field number and then the value (and for NED fields there additionally is a hash value). E.g.

• "#3":{"value":""}

Hope this helps. Regards, Daniel  

Take a look here: https://fiddle.sencha.com/#fiddle/9o7&view/editor Notice the input text of the "name" field on the right. Regards, Claudio

Claudio said Thanks Daniel, no problem. Last question: there is a "empty text" value for the widget when field is empty? Thanks again, and again Claudio  

 Thanks Claudio. And you are welcome. I, however, don't exactly understand what you mean by "there is a "empty text" value for the widget when field is empty". In case a field is empty then you should see in the JSON stream for the DSP a field number and then the value (and for NED fields there additionally is a hash value). E.g.

• "#3":{"value":""}

Hope this helps. Regards, Daniel

diseli said

Claudio said In my case the DATA channel is empty Regards Claudio  

$webinfo("DATA") should be filled in the Set State (STST) after the websave. And it seems that in the Get State (GTST) trigger the incoming data can be found in $webinfo("INPUT"). Sorry for the confusion, but the doc does not seem to be accurate here. Regards, Daniel  

Thanks Daniel, no problem. Last question: there is a "empty text" value for the widget when field is empty? Thanks again, and again Claudio

Claudio said In my case the DATA channel is empty Regards Claudio  

$webinfo("DATA") should be filled in the Set State (STST) after the websave. And it seems that in the Get State (GTST) trigger the incoming data can be found in $webinfo("INPUT"). Sorry for the confusion, but the doc does not seem to be accurate here. Regards, Daniel

Hello Claudio, This error generally comes when value of non modifiable widget is changed via javascript. Some widgets are non-modifiable by default, like StaticText, so if you set their values by JS_API, when the dsp is sent back to Uniface, this error is thrown. In this case, use StaticText_updatable instead.

Extract of usys.ini file :
[webwidgets]
StaticText=plain(rawhtml=false;clientsyntaxcheck=false)[syntax=ned,npr]
StaticText_updatable=plain(rawhtml=false;clientsyntaxcheck=false)[syntax=npr]
 

The problem is, that the webstat don't say which field is in error, so it could be difficult to find it.

Thanks Claudio. In that case we have to consider the following:

• the value of the DatePicker field is actually changed in the browser: since the field is defined as NED this is not allowed and will correctly trigger the -259 error upon webload; this might raise the question, if the field in question is correctly defined as NED or if it should be YED (it should be possible to edit field).
• the value of the DatePicker field is not changed in the browser round trip: if that's the case then we might face a new problem here (that AFAIK has not been reported before)

Anyway, in case you require further assistance with this issue then feel free to open a call with support (and provide an isolated test-set and a clear problem description). Regards, Daniel

Hi Daniel, the problem still remain. Regards Claudio

Hi Claudio, Thanks for your reply. But is the field in question (referenced by the "LOAD security error") a DatePicker field (as shown in the screen shot of the Define Component Field Properties form)? Then you could try if it helps to add the "datatype=string" property to the webwidgets definition of the DatePicker widget (in case you have not done this yet):

DatePicker=htmlinput(html:type=date;datatype=string) I (so far) have not encountered this issue with the DatePicker widget. But in the web project where we've encountered the -259 error no DatePicker fields were used. In case this not make a difference either, then you have to check if the value sent to the browser is the same as the one received back from the browser. You should be able to do this by checking $webinfo("DATA") in the Set State (STST) and the Get State (GTST) trigger of your DSP. Hope this helps. Regards, Daniel

diseli said Hi Claudio, No, you don't have to define this for every component. The mentioned INI settings are used for all DSP components. And it causes that the data of the specified fields are treated as string by the browser. This has no influence on the data-type definitions of the field in Uniface (a date field is still treated as date and not as string). Just give it a try. If the -259 error disappears then all should be fine. if not, then we are dealing with a completely different issue here. Hope this helps. Regards, Daniel  

Hi Daniel, the problem still remain. But from wasv.log I can read: "LOAD Security error: FieldValue of NON DB field [MYFIELD.MYTABLE.MYMODEL] has been modified"   Any other solution? Thanks again Regards Claudio

Hi Claudio, No, you don't have to define this for every component. The mentioned INI settings are used for all DSP components. And it causes that the data of the specified fields are treated as string by the browser. This has no influence on the data-type definitions of the field in Uniface (a date field is still treated as date and not as string). Just give it a try. If the -259 error disappears then all should be fine. if not, then we are dealing with a completely different issue here. Hope this helps. Regards, Daniel

Thanks Daniel, but I've not understood the problem I have. So, if I have this kind of fields:

I need to define in the USYS.INI the appropriate definition for every component? Thanks again Regards Claudio

Hello Claudio, I've also seen this problem when NED EditBox fields are using non-string data types. The problem went away when we added the property "datatype=string" to the webwidgets definition of the EditBox. You can find the definitions in the USYS.INI:

[webwidgets] ; Logical to physical widget mapping for DSPs ; HTML widgets ;EditBox=htmlinput(html:type=text;detail=dblclick) EditBox=htmlinput(html:type=text;detail=dblclick;datatype=string) And in case you ever face any binding problems with DSP list-widgets (like e.g. DropDownList and ListBox) then it might also help to add the mentioned property to these webwidgets:

;DropDownList=htmlselect(html:size=1) DropDownList=htmlselect(html:size=1;datatype=string) ;ListBox=htmlselect(html:size=3) ListBox=htmlselect(html:size=3;datatype=string) Just make sure that you update the correct USYS.INI (the one used by the UServer as specified in the UST). Hope this helps. Kind regards, Daniel iseli Uniface Technical Support

Philippe said Hello Claudio, This error generally comes when value of non modifiable widget is changed via javascript. Some widgets are non-modifiable by default, like StaticText, so if you set their values by JS_API, when the dsp is sent back to Uniface, this error is thrown. In this case, use StaticText_updatable instead.

Extract of usys.ini file :
[webwidgets]
StaticText=plain(rawhtml=false;clientsyntaxcheck=false)[syntax=ned,npr]
StaticText_updatable=plain(rawhtml=false;clientsyntaxcheck=false)[syntax=npr]
 

The problem is, that the webstat don't say which field is in error, so it could be difficult to find it.  

Thanks for your feedback Philippe. I'm sure to not use any kind of static widget, but there is a query to execute on repository in order to extract my DSP's field definitions for a global check? My DSP is quite complex, and open all elements one by one take a lot time. Thanks Claudio