selectkey working correctly in application examples

[JD Kromkowski]

1. How do you debug in this function of toolbar.sma function selectrecord(appwindow appw, string operation, boolean silent=.false) 2. I don’t think selectkey is working right. I thought I mentioned this before. If my selection is beyond the last record, I should get the last record. But I don’t I just get the same record I was on. does found have to be set to .true or is there something else the matter. found = .false e = 0 r =@ appw.form.selectkey(prompt, appw.form.masterrecord.record.index, found=found, error=e) if not found wxmessagedialog(appw.w, “Exact match not found”, appw.app.title, “ok”, “information”) appw.sb.settext(“Exact match not found”) delay = 2000000 !beginthread(clearstatusbar, appw.sb, delay) else if e == iERR_SBL_EOF or e == iERR_NORMALENDOFDATA //wxmessagedialog(appw.w, “End of table”, appw.app.title, “ok”, “information”) appw.sb.settext(“End of table”) delay = 2000000 !beginthread(clearstatusbar, appw.sb, delay)

[Michael]

On 21/02/2013 22:12, kromkowski wrote:
> 1. How do you debug in this function of toolbar.sma
>
> function selectrecord(appwindow appw, string operation, boolean
> silent=.false)
>
>
> 2. I don't think selectkey is working right. I thought I mentioned
> this before. If my selection is beyond the last record, I should get
> the last record. But I don't I just get the same record I was on.
>
> does found have to be set to .true or is there something else the matter.

First, selectkey can't go beyond the last record. It can fail, but it isn't like a selectnext(). If a selectkey fails, and you
supply a found flag, then it will return the next closest match (unless the file is empty), if you do not supply a found flag,
then it will just fail.

Ciao, Neil

[JD Kromkowski]

On 02/22/13 11:04 AM, Neil Robinson wrote:
> On 21/02/2013 22:12, kromkowski wrote:
>> 1. How do you debug in this function of toolbar.sma
>>
>> function selectrecord(appwindow appw, string operation, boolean
>> silent=.false)
>>
>>
>> 2. I don't think selectkey is working right. I thought I mentioned
>> this before. If my selection is beyond the last record, I should get
>> the last record. But I don't I just get the same record I was on.
>>
>> does found have to be set to .true or is there something else the matter.
>
> First, selectkey can't go beyond the last record. It can fail, but it isn't like a selectnext(). If a selectkey fails, and you
> supply a found flag, then it will return the next closest match (unless the file is empty), if you do not supply a found flag,
> then it will just fail.
>
> Ciao, Neil
>

If selectkey fails it should give you the closest match. We agree on this.

But it is not doing that when the closest match should be the last record.

For example,

rec1 Abigail
rec2 Charlie
rec3 David
rec4 Susan

If I selectkey on "Benjamin", I should get "Charlie", which I do.

If I selectkey on "Henry", I should get "Susan", which I do.

If I selectkey on "Xavier", I should also get "Susan", which I DON'T.

It is just a fail (regardless of whether you've supplied a found flag),
so you end up with whatever record you are on. This happens in Personal
as well as programatically.

Susan is the nearest match to "Xavier". So the proper behaviour

[Michael]

On 22/02/2013 17:21, kromkowski wrote:
> On 02/22/13 11:04 AM, Neil Robinson wrote:
>> First, selectkey can't go beyond the last record. It can fail, but it isn't like a selectnext(). If a selectkey fails, and you
>> supply a found flag, then it will return the next closest match (unless the file is empty), if you do not supply a found flag,
>> then it will just fail.
>>
>> Ciao, Neil
>>
>
>
> If selectkey fails it should give you the closest match. We agree on this.
>
> But it is not doing that when the closest match should be the last record.
>
> For example,
>
> rec1 Abigail
> rec2 Charlie
> rec3 David
> rec4 Susan
>
> If I selectkey on "Benjamin", I should get "Charlie", which I do.
>
> If I selectkey on "Henry", I should get "Susan", which I do.
>
> If I selectkey on "Xavier", I should also get "Susan", which I DON'T.
>
> It is just a fail (regardless of whether you've supplied a found flag),
> so you end up with whatever record you are on. This happens in Personal
> as well as programatically.
>
> Susan is the nearest match to "Xavier". So the proper behaviour

I have had a deeper look into this. It turns out the answer is more complicated than I would like. I will be having a look into
the internal behavior of sbme1 soon. As it turns out, when using PPCS and SBME, looking for values smaller than the smallest index
value return the first index entry. In PPCS, looking for values larger than the largest value return the last entry in the index.
In SBME, for reasons I can't recall (the design was 11-12 years ago), appears to return .nul and set the error value to 64 (Normal
End of Data). I have altered dataform1, printform1, recordview,and tableview to react to this by doing a select(.true) (select
last record) when it receives this result. They will be in the release this week. I will have a look to changing this behavior at
the sbme1 level for the next significant release.

Ciao, Neil

[Jim Locker]

Neil Robinson wrote:

> On 22/02/2013 17:21, kromkowski wrote:
>I will have a look to changing this behavior at
> the sbme1 level for the next significant release.

Please don't.

While I understand the issue, I think that you would do best to just say
"that is how it is, now", document it, and keep on rolling.
Alternatively, provide a flag that can be set to dictate the desired
behavior, with the default being the current behavior.

If you change it, you will break my code. I don't know how many others'
code will be broken, but changing behavior and causing regressions is
unlikely to win you friends.

[Michael]

On 27/02/2013 03:35, jim wrote:
> Neil Robinson wrote:
>
>> On 22/02/2013 17:21, kromkowski wrote:
>> I will have a look to changing this behavior at
>> the sbme1 level for the next significant release.
>
> Please don't.
>
> While I understand the issue, I think that you would do best to just say
> "that is how it is, now", document it, and keep on rolling.
> Alternatively, provide a flag that can be set to dictate the desired
> behavior, with the default being the current behavior.
>
> If you change it, you will break my code. I don't know how many others'
> code will be broken, but changing behavior and causing regressions is
> unlikely to win you friends.
>

I don't want to break existing code, but don't see how correcting it will do that. Even my own fix would simply never get called
in this case. Can you make a case for not fixing it, since the only workaround is to detect .nul and error 64 together?

Ciao, Neil

[JD Kromkowski]

From my perspective, it is wrong behavior for select key and should be
fixed.

I also can't understand how this would break code.

JDK

On 02/27/13 3:02 PM, Neil Robinson wrote:
> On 27/02/2013 03:35, jim wrote:
>> Neil Robinson wrote:
>>
>>> On 22/02/2013 17:21, kromkowski wrote:
>>> I will have a look to changing this behavior at
>>> the sbme1 level for the next significant release.
>>
>> Please don't.
>>
>> While I understand the issue, I think that you would do best to just say
>> "that is how it is, now", document it, and keep on rolling.
>> Alternatively, provide a flag that can be set to dictate the desired
>> behavior, with the default being the current behavior.
>>
>> If you change it, you will break my code. I don't know how many others'
>> code will be broken, but changing behavior and causing regressions is
>> unlikely to win you friends.
>>
>
> I don't want to break existing code, but don't see how correcting it will do that. Even my own fix would simply never get called
> in this case. Can you make a case for not fixing it, since the only workaround is to detect .nul and error 64 together?
>
> Ciao, Neil
>

[Author]

Posts