TOPIC: Troubles and (maybe) some bugs with IDControl
#92
Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Hi, I have encountered two problems with IDControl.

1) From my tests it seems to me that the IDControl is not working if its 'nameField' member is used with a 'not string' value (e.g. a number value). This is very limiting for my application because after the user has done a lookup on a master table, I have to display a number code in the edit field of an IDControl.

2) I have noticed that the field used in the 'nameField' member has to be a key or a index unique. In my application, the displayed value is not a unique value of the table. Only the primary key is a unique field. I think it is wrong to assume that the nameField should be a key, because, for example I could have 2 or more identical customer names, but they are different persons (omonimous). In this situation I would like to select the right customer from the list (from which I can see other informations that differentiate the omonimous customers) and display the selected name in the ID field, although it's not a unique value in its table.

There is a way to bypass these issues?

Post edited by: Mauro, at: 2006/03/04 15:42
 
 
Mauro
 
#94
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Another problem:

3) In the lookup list displayed when I click on an IDControl field, the date values are displayed in the format '#xxxxxxxx.yyyyyyyyy', although it is a date field ('Field_date {}' in my data dictionary).
Instead, in the access and browse controls this field is always displayed as a typical date 'dd/MM/yyyy' (as should it be).
 
 
Mauro
 
#95
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Basically, the answer to all three is that is the way IdControl was written - for names that are strings and are unique. Sorry!

IdControl requires names to be unique because we thought it would be confusing if what is displayed is not unique.

As a partial solution for this, we use a convention where we don't print (on reports) anything after an asterisk. So the unique names might be "WalMart*Newville" and "Walmart*Oldtown".

To meet your requirements you would have to write a new control. You could use Id/KeyControl as examples.
 
 
andrew
 
#97
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Ok, I was wrong in assuming that IDControl was created for a generic use. It's too bad that it isn't as generic as I would, because I think it would be a beautiful and very useful generic control.
Anyway, for now I have managed to solve the point (2) of my previous list of problems, by redefining this function in the IdFieldControl:

Code:

lookup_record(val, field = false, noRestrictions = false)
{
if val is ""
return false

if (field is false)
field = .nameField

// lookup value in table, applying whereField if applicable
q = .restrictionsValid or noRestrictions ? .base_query : .query;
if((whereField = .Send("GetWhereField")) isnt false)
{
wherevalue = .Send('GetField', whereField);
q = QueryAddWhere(q, " where " $ whereField $ " = " $ Display(wherevalue))
}
return Query1(QueryAddWhere(q, " where " $ field $ " = " $ Display(val)
$ " and " $ .numfield $ " = " $ .set_val)); //** <-- MY MOD! **
}



Basically, I have added some code in the last instruction, in order to select the record based on the .numfield value (the primary key), instead of the field value only (the 'field' value is filled with the nameField value passed to the control, that in my case it's not a key). In this way, the query doesn't go in error when the nameField is not unique. It appears to work.
Now, if I manage to resolve the problem (1) too, the IdControl could become enough generic for me. :)
 
 
Mauro
 
#98
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
IdControl did what was required up till now. It was as "generic" as it needed to be. That does not mean it handled every possible need. Even if it handled what you need, there would be other things it would not handle.

Thanks for the improvement. I hope you can figure out the rest. Keep the questions coming.
 
 
andrew
 
#100
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Hi, I think I have resolved the problem (1) too, plus another issue: in the bottom right Locate edit box of an AccessControl, the quick search was working only if the locate key field was a string type. Now is working for Number fields too.
To do the trick I have changed some code in IdFieldControl and KeyListView.

Here the mods:

In the IdFieldControl (to use not unique nameField too and to make it work with number field too):
Code:

lookup_record(val, field = false, noRestrictions = false)
{
if val is ""
return false

if (field is false)
field = .nameField

// lookup value in table, applying whereField if applicable
q = .restrictionsValid or noRestrictions ? .base_query : .query;
if((whereField = .Send("GetWhereField")) isnt false)
{
wherevalue = .Send('GetField', whereField);
q = QueryAddWhere(q, " where " $ whereField $ " = " $ Display(wherevalue))
}

// ********** BELOW THERE ARE THE CHANGES:
if Datadict(.numfield).Base?(Field_number) is true
temp_set_val = .set_val
else
temp_set_val = Display(.set_val)

if Datadict(field).Base?(Field_number) is true
temp_val = val
else
temp_val = Display(val)

if Datadict(field).Base?(Field_number) is true and String(val).Number?() is false
return false

if Datadict(.numfield).Base?(Field_number) is true and String(.set_val).Number?() is false
return false

return Query1(QueryAddWhere(q, " where " $ field $ " = " $ temp_val
$ " and " $ .numfield $ " = " $ temp_set_val));
// **********************************
}



In the KeyListView (to allow user searching with Number fields too, in the 'Locate' edit box of AccessControl and IdControl):
Code:

New(query, columns, prefix = "", access = false, prefixColumn = false,
keys = false, field = "", value = "", excludeSelect = #())
{
super(.layout(query, columns, prefix, access, prefixColumn, keys));
.wmin = .Xmin
.hmin = .Ymin
// retrieve and set saved width and height
if (false isnt keylist_info = .keylistview_info)
{
if (Number?(keylist_info.window_info.width))
.Xmin = Max(.wmin, keylist_info.window_info.width + 2)
if (Number?(keylist_info.window_info.height))
.Ymin = Max(.hmin, keylist_info.window_info.height + 2)
// don't know why you need the "+2"
}
.Select_vals = Record()
.list = .Vert.List;
.prefix_by = .Vert.GoHorz.prefix_by;
.field = .Vert.GoHorz.Field;
.list.SetStyle(LVS.REPORT | LVS.NOSORTHEADER | LVS.SINGLESEL | LVS.SHOWSELALWAYS);
.list.SetExtendedStyle(LVS_EX.FULLROWSELECT);
.list.SetMenu(#("Reset Columns"))

.prevproc = SetWindowProc(.field.Hwnd, GWL.WNDPROC, .Fieldproc);
.access = access
.query = query
.excludeSelect = excludeSelect
// look up current record based on field and value passed in
//********** BELOW THERE ARE THE CHANGES (4 rows added and 1 modified)
if (field isnt "" and Datadict(field).Base?(Field_number) is true)
temp_value = value
else
temp_value = Display(value)
if (field isnt "" and value isnt "" and
false isnt rec = Query1(QueryAddWhere(query, " where " $ field $ " is " $ temp_value)))
.field.Set(rec[.prefixColumn])
else
.field.Set(prefix)
.prefix_by.Set(SelectPrompt(.prefixColumn))
.NewValue(SelectPrompt(.prefixColumn), .prefix_by)
Delayed(0, .set_initial_focus)
}

field_change()
{
//*** MY CHANGES
//.field.Get() returns a string, but for a Number field we have to return a Number,
//otherwise the search will not work. So, we have to control the data dictionary
//and eventually convert the value in a Number:
if (Datadict(.prefixColumn).Base?(Field_number) is true)
temp_field = Number(.field.Get())
else
temp_field = .field.Get()
//i = .list.Seek(.prefixColumn, .field.Get())
i = .list.Seek(.prefixColumn, temp_field)
.list.SelectItem(i)
}



Post edited by: Mauro, at: 2006/03/06 11:42
 
 
Mauro
 
#102
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Thanks again! I will check it and assuming no problems, add it to stdlib.
 
 
andrew
 
#103
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
I'm glad to help. :)
Make sure that the mods works well before update stdlib.
I have not checked yet if there are problems with date values.
 
 
Mauro
 
#130
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Sorry, this did not make it into the new release. I looked at it, but I had some questions and I did not get a chance to investigate.
 
 
andrew
 
#131
Re:Troubles and (maybe) some bugs with IDControl 4 Years, 5 Months ago
Don't worry. ;) I think that it is better to check them well, before inserting in stdlib.
 
 
Mauro