PDA

View Full Version : New Problem with doFind operation in 1-1



Nicolas Gerig
7-Jan-2008, 12:58 PM
Since we have updated to ajax version 1-1 our js commands aren't working
correctly anymore!!!

Code:
function jsLoad() {

var oProject_No =
document.getElementById("cd11proj__project_no");
oProject_No.value = sProject_No ;
var oForm = findForm(oProject_No);
oForm.doFind("EQ", "cd11proj", false);

var oStudy_No = document.getElementById("cd11stud__study_no");
oStudy_No.value = sStudy_No;
var oForm = findForm(oStudy_No);
oForm.doFind("EQ", "cd11stud", false);

var oCenter_No =
document.getElementById("cd11cent__center_no");
oCenter_No.value = sCenter_No;
var oForm = findForm(oCenter_No);
oForm.doFind("EQ", "cd11cent", false);

jsLoad gets the wanted record into the buffer and the information is
automatically loaded into the html fields.
It worked fine in 1.1 beta1 and now just the first table (cd11proj)
finds it's record.

While debugging I realized, that the second parameter of the doFind
command should be an "object" or it will take the last focused field.

Important Code: VdfForm.js, Line 688 to 694:
VdfForm.prototype.doFind = function(sFindMode, oField, bSuppressError){
var sXml = new JStringBuilder(), sIndex;

try{
if(typeof(oField) != "object"){
var oField = this.oLastFocus;
}

Well, the problem now is, cd11proj__project_no is (now in 1-1) always
the last focused field.
Copying a value into cd11stud__study_no does not focus this field
anymore (the way it used to do in 1.1 beta).

I tried different things:
1) to get the second parameter right so it is an "object" and the
library does not take the last focused.
2) To set the focus via JavaScript to the field I want to have focused.
For none of these I found a working syntax.
For example (I tried to):
oForm.doFind("EQ", oStudy_No, false)
oForm.doFind("EQ", "cd11stud__study_no", false)
browser.dom.setFocus(oStudy_No);
oStudy_No.focus();
oField.oLastFocus = oStudy_No;

After 3 hours I gave up!

Why is there a change in this AJAX library's behavior?
How can I write a Vdf-Field correctly so the doFind function accepts it
as an "object"?
How can I set focus to a field of my choice?

Thanks for ur help!
Nicolas Gerig

Harm Wibier
8-Jan-2008, 05:06 AM
Hello Nicolas,

There have been changes to the interface of the doFind method. The object
that it expects as a second parameter is a VdfField object (you can find
this in the Reference Guide available in the help file). This VdfField
object is an wrapper object that equalizes the interfaces for the different
field types. The getField method of the VdfForm can be used to get an
reference to this VdfField object. The updated code should look something
like this:

var oForm = getVdfControl("cd11_form"); // "cdf11_form" is the
vdfControlName of the form

var oProject_No = oForm.getField("cd11proj__project_no");
oProject_No.setValue(sProject_No);
oForm.doFind("EQ", oProject_No, false);

var oStudy_No = oForm.getField("cd11stud__study_no");
oStudy_No.setValue(sStudy_No);
oForm.doFind("EQ", oStudy_No, false);

var oCenter_No = oForm.getField("cd11cent__center_no");
oCenter_No.setValue(sCenter_No);
oForm.doFind("EQ", oCenter_No, false);

Maybe the release notes aren't clear enough on this change. The change in
the interface is made because we switched to using File_Field_Find on the
server because we found out that there where to many differences in the
behavior with the windows interface. This required the all the forms finds
to be performed on specific fields instead of table indexes.

I hope this helps you fixing the broken code!

--
Regards,


Harm Wibier
Data Access Europe B.V.
http://www.dataaccess.nl/


"Nicolas Gerig" <ng@m-m.ag> wrote in message
news:uWzzkbVUIHA.4680@dacmail.dataaccess.com...
> Since we have updated to ajax version 1-1 our js commands aren't working
> correctly anymore!!!
>
> Code:
> function jsLoad() {
> .
> var oProject_No =
> document.getElementById("cd11proj__project_no");
> oProject_No.value = sProject_No ;
> var oForm = findForm(oProject_No);
> oForm.doFind("EQ", "cd11proj", false);
>
> var oStudy_No = document.getElementById("cd11stud__study_no");
> oStudy_No.value = sStudy_No;
> var oForm = findForm(oStudy_No);
> oForm.doFind("EQ", "cd11stud", false);
>
> var oCenter_No =
> document.getElementById("cd11cent__center_no");
> oCenter_No.value = sCenter_No;
> var oForm = findForm(oCenter_No);
> oForm.doFind("EQ", "cd11cent", false);
>
> jsLoad gets the wanted record into the buffer and the information is
> automatically loaded into the html fields.
> It worked fine in 1.1 beta1 and now just the first table (cd11proj) finds
> it's record.
>
> While debugging I realized, that the second parameter of the doFind
> command should be an "object" or it will take the last focused field.
>
> Important Code: VdfForm.js, Line 688 to 694:
> VdfForm.prototype.doFind = function(sFindMode, oField, bSuppressError){
> var sXml = new JStringBuilder(), sIndex;
>
> try{
> if(typeof(oField) != "object"){
> var oField = this.oLastFocus;
> }
>
> Well, the problem now is, cd11proj__project_no is (now in 1-1) always the
> last focused field.
> Copying a value into cd11stud__study_no does not focus this field anymore
> (the way it used to do in 1.1 beta).
>
> I tried different things:
> 1) to get the second parameter right so it is an "object" and the library
> does not take the last focused.
> 2) To set the focus via JavaScript to the field I want to have focused.
> For none of these I found a working syntax.
> For example (I tried to):
> oForm.doFind("EQ", oStudy_No, false)
> oForm.doFind("EQ", "cd11stud__study_no", false)
> browser.dom.setFocus(oStudy_No);
> oStudy_No.focus();
> oField.oLastFocus = oStudy_No;
>
> After 3 hours I gave up!
>
> Why is there a change in this AJAX library's behavior?
> How can I write a Vdf-Field correctly so the doFind function accepts it as
> an "object"?
> How can I set focus to a field of my choice?
>
> Thanks for ur help!
> Nicolas Gerig

Nicolas Gerig
8-Jan-2008, 08:57 AM
Thanks a lot for these syntax examples.
Now while debugging everything seems to run correctly.

But I still have the problem that just the first record (project) is found:

var oForm = getVdfControl("<%=vdfMainTable%>_form");

var oProject_No = oForm.getField("cd11proj__project_no");
oProject_No.setValue(sProject_No);
oForm.doFind("EQ", oProject_No, false);
//works fine

var oStudy_No = oForm.getField("cd11stud__study_no");
oStudy_No.setValue(sStudy_No);
oForm.doFind("EQ", oStudy_No, false);


Strange thing is: The code is exactly the same, debugging shows that
every variable is found and filled.
Debugging the doFind action shows about the same information.
So I tried to get an Idea about the xml...
I compared the sended xml
and realised the following:
When sending the doFind command for the oProject_No every Input field is
written in the xml as:
<TAjaxRequestCol> <sName>cd11proj.project_no</sName> <sType>D</sType>
<bChangedState>false</bChangedState> <sValue><![CDATA[99046]]></sValue>
</TAjaxRequestCol>

But if I debug the code for oStudy_No it gets a small difference:
Every Input is sended same way as when we find the oProject_No
BUT cd11stud.study_no is different, has a bChangedState of true...
<TAjaxRequestCol> <sName>cd11stud.study_no</sName> <sType>D</sType>
<bChangedState>true</bChangedState> <sValue><![CDATA[990460]]></sValue>
</TAjaxRequestCol>

Well, I am not sure if that should be that way or not, to me its just a
strange behaviuour because it is acting different than the one before...

btw. When I press save, i get an error at the study_no field.
A Value should not be changed error... (added a picture)

Well... So I am a bit confused now...

mfg Nicolas Gerig

Harm Wibier schrieb:
> Hello Nicolas,
>
> There have been changes to the interface of the doFind method. The object
> that it expects as a second parameter is a VdfField object (you can find
> this in the Reference Guide available in the help file). This VdfField
> object is an wrapper object that equalizes the interfaces for the different
> field types. The getField method of the VdfForm can be used to get an
> reference to this VdfField object. The updated code should look something
> like this:
>
> var oForm = getVdfControl("cd11_form"); // "cdf11_form" is the
> vdfControlName of the form
>
> var oProject_No = oForm.getField("cd11proj__project_no");
> oProject_No.setValue(sProject_No);
> oForm.doFind("EQ", oProject_No, false);
>
> var oStudy_No = oForm.getField("cd11stud__study_no");
> oStudy_No.setValue(sStudy_No);
> oForm.doFind("EQ", oStudy_No, false);
>
> var oCenter_No = oForm.getField("cd11cent__center_no");
> oCenter_No.setValue(sCenter_No);
> oForm.doFind("EQ", oCenter_No, false);
>
> Maybe the release notes aren't clear enough on this change. The change in
> the interface is made because we switched to using File_Field_Find on the
> server because we found out that there where to many differences in the
> behavior with the windows interface. This required the all the forms finds
> to be performed on specific fields instead of table indexes.
>
> I hope this helps you fixing the broken code!
>

Nicolas Gerig
8-Jan-2008, 09:00 AM
I added the wrong picture sorry.

Nicolas Gerig schrieb:
> Thanks a lot for these syntax examples.
> Now while debugging everything seems to run correctly.
>
> But I still have the problem that just the first record (project) is found:
>
> var oForm = getVdfControl("<%=vdfMainTable%>_form");
>
> var oProject_No = oForm.getField("cd11proj__project_no");
> oProject_No.setValue(sProject_No);
> oForm.doFind("EQ", oProject_No, false);
> //works fine
>
> var oStudy_No = oForm.getField("cd11stud__study_no");
> oStudy_No.setValue(sStudy_No);
> oForm.doFind("EQ", oStudy_No, false);
>
>
> Strange thing is: The code is exactly the same, debugging shows that
> every variable is found and filled.
> Debugging the doFind action shows about the same information.
> So I tried to get an Idea about the xml...
> I compared the sended xml
> and realised the following:
> When sending the doFind command for the oProject_No every Input field is
> written in the xml as:
> <TAjaxRequestCol> <sName>cd11proj.project_no</sName> <sType>D</sType>
> <bChangedState>false</bChangedState> <sValue><![CDATA[99046]]></sValue>
> </TAjaxRequestCol>
>
> But if I debug the code for oStudy_No it gets a small difference:
> Every Input is sended same way as when we find the oProject_No
> BUT cd11stud.study_no is different, has a bChangedState of true...
> <TAjaxRequestCol> <sName>cd11stud.study_no</sName> <sType>D</sType>
> <bChangedState>true</bChangedState> <sValue><![CDATA[990460]]></sValue>
> </TAjaxRequestCol>
>
> Well, I am not sure if that should be that way or not, to me its just a
> strange behaviuour because it is acting different than the one before...
>
> btw. When I press save, i get an error at the study_no field.
> A Value should not be changed error... (added a picture)
>
> Well... So I am a bit confused now...
>
> mfg Nicolas Gerig
>
> Harm Wibier schrieb:
>> Hello Nicolas,
>>
>> There have been changes to the interface of the doFind method. The
>> object that it expects as a second parameter is a VdfField object (you
>> can find this in the Reference Guide available in the help file). This
>> VdfField object is an wrapper object that equalizes the interfaces for
>> the different field types. The getField method of the VdfForm can be
>> used to get an reference to this VdfField object. The updated code
>> should look something like this:
>>
>> var oForm = getVdfControl("cd11_form"); // "cdf11_form" is the
>> vdfControlName of the form
>>
>> var oProject_No = oForm.getField("cd11proj__project_no");
>> oProject_No.setValue(sProject_No);
>> oForm.doFind("EQ", oProject_No, false);
>>
>> var oStudy_No = oForm.getField("cd11stud__study_no");
>> oStudy_No.setValue(sStudy_No);
>> oForm.doFind("EQ", oStudy_No, false);
>>
>> var oCenter_No = oForm.getField("cd11cent__center_no");
>> oCenter_No.setValue(sCenter_No);
>> oForm.doFind("EQ", oCenter_No, false);
>>
>> Maybe the release notes aren't clear enough on this change. The change
>> in the interface is made because we switched to using File_Field_Find
>> on the server because we found out that there where to many
>> differences in the behavior with the windows interface. This required
>> the all the forms finds to be performed on specific fields instead of
>> table indexes.
>>
>> I hope this helps you fixing the broken code!
>>
>
>
> ------------------------------------------------------------------------
>

Harm Wibier
8-Jan-2008, 09:33 AM
The error is caused because the changedstate of the field is set to true
when you change the value. Performing a find EQ on this field should cause
the changedstate to go to false again. It is not totally clear to me what
happens here. A few questions

Does the find request for the study find contain the correct (new) value for
the cd11stud__study_no?
At the start of the find request are the xml tags <sTable> and <sColumn>,
are these correct ("cd11stud" and "study_no")?
What is the datamodel to which cd11stud belongs?
Is the cd11stud__study field inside an index? Are there more fields inside
this index? How does this index look like?

--
Regards,


Harm Wibier
Data Access Europe B.V.
http://www.dataaccess.nl/


"Nicolas Gerig" <ng@m-m.ag> wrote in message
news:lYmPz5fUIHA.4680@dacmail.dataaccess.com...
> Thanks a lot for these syntax examples.
> Now while debugging everything seems to run correctly.
>
> But I still have the problem that just the first record (project) is
> found:
>
> var oForm = getVdfControl("<%=vdfMainTable%>_form");
>
> var oProject_No = oForm.getField("cd11proj__project_no");
> oProject_No.setValue(sProject_No);
> oForm.doFind("EQ", oProject_No, false);
> //works fine
>
> var oStudy_No = oForm.getField("cd11stud__study_no");
> oStudy_No.setValue(sStudy_No);
> oForm.doFind("EQ", oStudy_No, false);
>
>
> Strange thing is: The code is exactly the same, debugging shows that
> every variable is found and filled.
> Debugging the doFind action shows about the same information.
> So I tried to get an Idea about the xml...
> I compared the sended xml
> and realised the following:
> When sending the doFind command for the oProject_No every Input field is
> written in the xml as:
> <TAjaxRequestCol> <sName>cd11proj.project_no</sName> <sType>D</sType>
> <bChangedState>false</bChangedState> <sValue><![CDATA[99046]]></sValue>
> </TAjaxRequestCol>
>
> But if I debug the code for oStudy_No it gets a small difference:
> Every Input is sended same way as when we find the oProject_No
> BUT cd11stud.study_no is different, has a bChangedState of true...
> <TAjaxRequestCol> <sName>cd11stud.study_no</sName> <sType>D</sType>
> <bChangedState>true</bChangedState> <sValue><![CDATA[990460]]></sValue>
> </TAjaxRequestCol>
>
> Well, I am not sure if that should be that way or not, to me its just a
> strange behaviuour because it is acting different than the one before...
>
> btw. When I press save, i get an error at the study_no field.
> A Value should not be changed error... (added a picture)
>
> Well... So I am a bit confused now...
>
> mfg Nicolas Gerig
>
> Harm Wibier schrieb:
>> Hello Nicolas,
>>
>> There have been changes to the interface of the doFind method. The object
>> that it expects as a second parameter is a VdfField object (you can find
>> this in the Reference Guide available in the help file). This VdfField
>> object is an wrapper object that equalizes the interfaces for the
>> different
>> field types. The getField method of the VdfForm can be used to get an
>> reference to this VdfField object. The updated code should look something
>> like this:
>>
>> var oForm = getVdfControl("cd11_form"); // "cdf11_form" is the
>> vdfControlName of the form
>>
>> var oProject_No = oForm.getField("cd11proj__project_no");
>> oProject_No.setValue(sProject_No);
>> oForm.doFind("EQ", oProject_No, false);
>>
>> var oStudy_No = oForm.getField("cd11stud__study_no");
>> oStudy_No.setValue(sStudy_No);
>> oForm.doFind("EQ", oStudy_No, false);
>>
>> var oCenter_No = oForm.getField("cd11cent__center_no");
>> oCenter_No.setValue(sCenter_No);
>> oForm.doFind("EQ", oCenter_No, false);
>>
>> Maybe the release notes aren't clear enough on this change. The change in
>> the interface is made because we switched to using File_Field_Find on
>> the
>> server because we found out that there where to many differences in the
>> behavior with the windows interface. This required the all the forms
>> finds
>> to be performed on specific fields instead of table indexes.
>>
>> I hope this helps you fixing the broken code!
>>
>
>

Nicolas Gerig
8-Jan-2008, 09:58 AM
Harm Wibier schrieb:
> The error is caused because the changedstate of the field is set to true
> when you change the value. Performing a find EQ on this field should cause
> the changedstate to go to false again. It is not totally clear to me what
> happens here. A few questions
>
> Does the find request for the study find contain the correct (new) value for
> the cd11stud__study_no?
<TAjaxRequestCol>
<sName>cd11stud.study_no</sName>
<sType>D</sType>
<bChangedState>true</bChangedState>
<sValue><![CDATA[ 990460 ]]></sValue>
</TAjaxRequestCol>

It is the correct value.

> At the start of the find request are the xml tags <sTable> and <sColumn>,
> are these correct ("cd11stud" and "study_no")?
<sTable>cd11stud</sTable>
<sColumn>study_no</sColumn>
yes, correct.

> What is the datamodel to which cd11stud belongs?
probably best answered if I add a def file.
cd11proj is cd11stud's parent.

> Is the cd11stud__study field inside an index? Are there more fields inside
> this index? How does this index look like?
Yes it is, Index 1. I checked also if ajax is using the right index
information.
the index is:
-cd11stud.project_no
-cd11stud.study_no

cd11stud.project_no is related to cd11proj.project_no

in the .wo it looks like that:

Object oCd11proj_DD is a Cd11proj_DataDictionary
Send DefineAllExtendedFields
End_Object

Object oCd11stud_DD is a Cd11stud_DataDictionary
Set Constrain_file to Cd11Proj.File_number
Set DDO_Server to oCd11proj_DD
Send DefineAllExtendedFields
End_Object

mfg
Nicolas Gerig

-----------------------------------------------------------------------------
DATE: 08.01.2008 TIME: 15:54 PAGE: 1
FILE DEFINITION FOR FILE: Cd11Stud (# 461)
-----------------------------------------------------------------------------
DRIVER NAME : DATAFLEX
FILE ROOT NAME : Cd11Stud
USER DISPLAY NAME : Cd11Stud
DATAFLEX FILE NAME : Cd11Stud
-----------------------------------------------------------------------------
RECORD LENGTH : 1280 ( USED: 1195 )
MAX NUMBER OF RECORDS : 10000 ( USED: 1 )
FILE COMPRESSION : NONE
RE-USE DELETED SPACE : YES
LOCKING TYPE : FILE
HEADER INTEGRITY CHECKING : YES
TRANSACTION TYPE : CLIENT ATOMIC
RECORD IDENTITY INDEX : 0 ( 0 , 0 )
FILE LOGIN PARAMETER :
SYSTEM FILE : NO
-----------------------------------------------------------------------------

NUM FIELD NAME TYPE SIZE OFFST IX RELATES TO FILE.FIELD
--- --------------- ---- ----- ----- -- ---------------------------------
1 Ident_No NUM 14.0 1
2 Project_No NUM 6.0 8 1 Cd11Proj.FIELD_2 (460,2)
3 Study_No NUM 6.0 11 1
4 Title_01 ASC 50 14
5 StartDate DAT 6 64
6 Fees_No NUM 4.0 67
7 LastCentNo NUM 4.0 69
8 Status ASC 5 71
9 CreaDate DAT 6 76
10 CreaTime ASC 10 79
11 Crea_Ini ASC 15 89
12 UpdaDate DAT 6 104
13 UpdaTime ASC 10 107
14 Upda_Ini ASC 15 117
15 HashStamp ASC 40 132
16 Comment TEX 1024 172


INDEX# FIELDS DES U/C LENGTH LEVELS SEGMENTS MODE
------ --------------- --- --- ------ ------ -------- -------
1 Project_No NO NO 6 3 2 ON-LINE
Study_No NO NO

Harm Wibier
8-Jan-2008, 11:02 AM
Hello Nicolas,

Have you set the server table (vdfServerTable) for the fields in child table
(cd11stud)? This can influence the find behavior. This can be done groupwise
by surrounding the fields from this table with a div (or a table or
something) and creating a group control (like <div vdfControlType="group"
vdfControlName="orderdtl_group" vdfServerTable="orderdtl">.

--
Regards,


Harm Wibier
Data Access Europe B.V.
http://www.dataaccess.nl/

"Nicolas Gerig" <ng@m-m.ag> wrote in message
news:IuVqwbgUIHA.4680@dacmail.dataaccess.com...
> Harm Wibier schrieb:
>> The error is caused because the changedstate of the field is set to true
>> when you change the value. Performing a find EQ on this field should
>> cause
>> the changedstate to go to false again. It is not totally clear to me what
>> happens here. A few questions
>>
>> Does the find request for the study find contain the correct (new) value
>> for
>> the cd11stud__study_no?
> <TAjaxRequestCol>
> <sName>cd11stud.study_no</sName>
> <sType>D</sType>
> <bChangedState>true</bChangedState>
> <sValue><![CDATA[ 990460 ]]></sValue>
> </TAjaxRequestCol>
>
> It is the correct value.
>
>> At the start of the find request are the xml tags <sTable> and <sColumn>,
>> are these correct ("cd11stud" and "study_no")?
> <sTable>cd11stud</sTable>
> <sColumn>study_no</sColumn>
> yes, correct.
>
>> What is the datamodel to which cd11stud belongs?
> probably best answered if I add a def file.
> cd11proj is cd11stud's parent.
>
>> Is the cd11stud__study field inside an index? Are there more fields
>> inside
>> this index? How does this index look like?
> Yes it is, Index 1. I checked also if ajax is using the right index
> information.
> the index is:
> -cd11stud.project_no
> -cd11stud.study_no
>
> cd11stud.project_no is related to cd11proj.project_no
>
> in the .wo it looks like that:
>
> Object oCd11proj_DD is a Cd11proj_DataDictionary
> Send DefineAllExtendedFields
> End_Object
>
> Object oCd11stud_DD is a Cd11stud_DataDictionary
> Set Constrain_file to Cd11Proj.File_number
> Set DDO_Server to oCd11proj_DD
> Send DefineAllExtendedFields
> End_Object
>
> mfg
> Nicolas Gerig
>


--------------------------------------------------------------------------------


> -----------------------------------------------------------------------------
> DATE: 08.01.2008 TIME: 15:54 PAGE:
> 1
> FILE DEFINITION FOR FILE: Cd11Stud (# 461)
> -----------------------------------------------------------------------------
> DRIVER NAME : DATAFLEX
> FILE ROOT NAME : Cd11Stud
> USER DISPLAY NAME : Cd11Stud
> DATAFLEX FILE NAME : Cd11Stud
> -----------------------------------------------------------------------------
> RECORD LENGTH : 1280 ( USED: 1195 )
> MAX NUMBER OF RECORDS : 10000 ( USED: 1 )
> FILE COMPRESSION : NONE
> RE-USE DELETED SPACE : YES
> LOCKING TYPE : FILE
> HEADER INTEGRITY CHECKING : YES
> TRANSACTION TYPE : CLIENT ATOMIC
> RECORD IDENTITY INDEX : 0 ( 0 , 0 )
> FILE LOGIN PARAMETER :
> SYSTEM FILE : NO
> -----------------------------------------------------------------------------
>
> NUM FIELD NAME TYPE SIZE OFFST IX RELATES TO FILE.FIELD
> --- --------------- ---- ----- ----- -- ---------------------------------
> 1 Ident_No NUM 14.0 1
> 2 Project_No NUM 6.0 8 1 Cd11Proj.FIELD_2 (460,2)
> 3 Study_No NUM 6.0 11 1
> 4 Title_01 ASC 50 14
> 5 StartDate DAT 6 64
> 6 Fees_No NUM 4.0 67
> 7 LastCentNo NUM 4.0 69
> 8 Status ASC 5 71
> 9 CreaDate DAT 6 76
> 10 CreaTime ASC 10 79
> 11 Crea_Ini ASC 15 89
> 12 UpdaDate DAT 6 104
> 13 UpdaTime ASC 10 107
> 14 Upda_Ini ASC 15 117
> 15 HashStamp ASC 40 132
> 16 Comment TEX 1024 172
>
>
> INDEX# FIELDS DES U/C LENGTH LEVELS SEGMENTS MODE
> ------ --------------- --- --- ------ ------ -------- -------
> 1 Project_No NO NO 6 3 2 ON-LINE
> Study_No NO NO
>
>

Nicolas Gerig
8-Jan-2008, 12:15 PM
> Hello Nicolas,
>
> Have you set the server table (vdfServerTable) for the fields in child table
> (cd11stud)?

No I did not...

This can influence the find behavior. This can be done groupwise
> by surrounding the fields from this table with a div (or a table or
> something) and creating a group control (like <div vdfControlType="group"
> vdfControlName="orderdtl_group" vdfServerTable="orderdtl">.
>

Well, I started a try:
....

<tr vdfControlType="group" vdfControlName="cd11stud_group"
vdfServerTable="cd11stud">
<td>Study</td>
<td><input id="cd11stud__study_no" name="cd11stud__study_no"
style="width:5em;" disabled="disabled"/>
<span id="Cd11stud__study_no__error" Class="Error" />
</td>
<td><input name="Cd11stud__title_01" style="width:20em;"
disabled="disabled"/><span id="Cd11stud__title_01__error" Class="Error" />
</td>
<td class="Data"> <select SIZE="1" NAME="cd11stud__Status"
disabled="disabled"><%=oWbo.DDValue("cd11stud.Status",DDOPTION)%>
</select><span id="Cd11stud__status__error" Class="Error" />
</tr>
....

But unfortunately there is no change in it's behavior...

Harm Wibier
9-Jan-2008, 05:46 AM
Well, it seems like the problem is somewhere on the server side application.
Best would be to debug the AjaxFindByField method of the
AjaxWebBusinessProcess class in the webapp. This method is new since the
Beta 2 and the difference with the normal find method is that it uses
File_Field_Find to perform the find (instead of Request_Find).

--
Regards,


Harm Wibier
Data Access Europe B.V.
http://www.dataaccess.nl/


"Nicolas Gerig" <ng@m-m.ag> wrote in message
news:r9$MBohUIHA.4084@dacmail.dataaccess.com...
>
>> Hello Nicolas,
>>
>> Have you set the server table (vdfServerTable) for the fields in child
>> table (cd11stud)?
>
> No I did not...
>
> This can influence the find behavior. This can be done groupwise
>> by surrounding the fields from this table with a div (or a table or
>> something) and creating a group control (like <div vdfControlType="group"
>> vdfControlName="orderdtl_group" vdfServerTable="orderdtl">.
>>
>
> Well, I started a try:
> ...
>
> <tr vdfControlType="group" vdfControlName="cd11stud_group"
> vdfServerTable="cd11stud">
> <td>Study</td>
> <td><input id="cd11stud__study_no" name="cd11stud__study_no"
> style="width:5em;" disabled="disabled"/>
> <span id="Cd11stud__study_no__error" Class="Error" />
> </td>
> <td><input name="Cd11stud__title_01" style="width:20em;"
> disabled="disabled"/><span id="Cd11stud__title_01__error" Class="Error" />
> </td>
> <td class="Data"> <select SIZE="1" NAME="cd11stud__Status"
> disabled="disabled"><%=oWbo.DDValue("cd11stud.Status",DDOPTION)%>
> </select><span id="Cd11stud__status__error" Class="Error" />
> </tr>
> ...
>
> But unfortunately there is no change in it's behavior...

Nicolas Gerig
9-Jan-2008, 08:30 AM
Harm Wibier schrieb:
> Well, it seems like the problem is somewhere on the server side application.
> Best would be to debug the AjaxFindByField method of the
> AjaxWebBusinessProcess class in the webapp. This method is new since the
> Beta 2 and the difference with the normal find method is that it uses
> File_Field_Find to perform the find (instead of Request_Find).
>

Well, I have changed a lot now.
with asp i call a .wo Procedure wich does the loading now.
And I might call this function later on also with that RMI stuff...

So I need more code at the server side, but I think that doesnt really
matter.

Well, I have a working solution now.