Look what I found! TIV=1808

With my code:
choice.mark.occur:
after.choice:
if sel.num.selected() > 0 then
do.selection(true, one.repair.one.marked.line)
endif

function one.repair.one.marked.line()
{
if actual.occ = 6 then
process.this.record()
else
wrong.record.selected()
endif
}
Multi occ screen with session in debug.
Click on a line somewhere in the middle (actual.occ: 6)
Only function wrong.record.selected() is executed, because actual.occ = filled.occ

Good one :) Would like to put my hands.

I must be missing something - now sure I get what you are saying. I know in 4c4 I can mark records and process them one at a time. Of course I am not sure that sel.num.selected is available - never used it.

There has been this new version (Infor ERP LN 6.1) and the update (TIV 1075) where they figured out that once a marked record is scrolled off the screen, it should still be marked. So they introduced new functionality and documented it in the ERP LN Tools Manual under "Improved Record selection Cookbook" (quotes can be found on the forum). Yet, once the record is being processed - even with a call to make.current() does not make the marked line the current record buffer, this is either the first or the last record on screen...

I recently got the latest Prog Guide and I am quite impressed. Lots of new stuff added which was I guess undocumented and a lot of new functions are introduced. As I always say, LN Rocks ;)

Look what I found! TIV=1808

With my code:
choice.mark.occur:
after.choice:
if sel.num.selected() > 0 then
do.selection(true, one.repair.one.marked.line)
endif

function one.repair.one.marked.line()
{
if actual.occ = 6 then
process.this.record()
else
wrong.record.selected()
endif
}
Multi occ screen with session in debug.
Click on a line somewhere in the middle (actual.occ: 6)
Only function wrong.record.selected() is executed, because actual.occ = filled.occ
Actually, I obviously make the error thinking the do.selection() should also modify the internal 4GL variable actual.occ, which is not the case.

My problem however is that I notice that the current record-buffer within the function one.repair.one.marked.line() appears to be the record of the last filled occurrence instead of the selected record (keyfields, other tablefields).

My actual code looks more like:
function one.repair.one.marked.line()
{
if selection.key1 = whinh215._index1 then
process.this.record()
else
if filled.occ.key1 = whinh215._index1 then
appears.last.record()
else
if first.record.key1 = whinh215._index1 then
appears.first.record()
else
other.wrong.record()
endif
endif
endif
}

How can I ensure that the record buffer is filled with the actual selected record(s)? I assume "the tools" should take care of that, not me as a programmer. But maybe I overlook something...:confused:

I recently got the latest Prog Guide and I am quite impressed. Lots of new stuff added which was I guess undocumented and a lot of new functions are introduced. As I always say, LN Rocks ;)

Some of us don't get to play with ln. :)

Now I get it - scrolling a marked record off the screen and it still shows as marked. I can only do marked records on current screen - that would be great.

Some of us don't get to play with ln. :)

Now I get it - scrolling a marked record off the screen and it still shows as marked. I can only do marked records on current screen - that would be great.So what is your TIV? (shown by the Help-About-System Information session in the BW interface - rightclick on the icon in the systray). Might be over 1075 voor BaanIV?

Not online at work right now. In this something you get by looking at the baan bwc client - not sure where this right click might be. Remember we are still on 4c4.

Some of us don't get to play with ln. :)


Mark,

I see you posting many times that you are soon going to acquire LN. So, you better start preparing a to-do list ;)

I am sure you are going to have a lot of playing with LN tools. :)

Hi OmeLuuk,

please use an external function called from a form command (specific option) instead of choice.mark.occur.


|choice.mark.occur:
|after.choice:

function extern my.form.command()
{
if sel.num.selected() > 0 then
do.selection(true, one.repair.one.marked.line)
endif
}

function one.repair.one.marked.line()
{
if table.field = xyz then
process.this.record()
else
wrong.record.selected()
endif
}

Mark,

I see you posting many times that you are soon going to acquire LN. So, you better start preparing a to-do list ;)

I am sure you are going to have a lot of playing with LN tools. :)

If we are lucky with the budgets then maybe in 2015. We are looking at doing a database upgrade and SP in 2014. At least that is what I was told, but you never know.

Hi OmeLuuk,

please use an external function called from a form command (specific option) instead of choice.mark.occur.
Alas this did not do the trick. What I would like to have: right after marking a line and as soon as certain conditions are met ('lack of data' in the data-setup) sessions pop up to add the data needed, for the items on the marked line.

The problems started when I added a different sort order based on a non-index field in a reference table instead of using the "normal, index based" sort order. I created an incident (in order to have a defect created) with a reproduction scenario (plain new stripped session) . See what happens. I'll keep you posted.

Hi OmeLuuk,

I don't quite get what you meant but if you think the problem has something to do with the TIV 1808 you can always chose a lower TIV in maintain script session form and recompile. I had a problem with fixed/based variables and chosing a lower TIV (in my case 1000) resolved it.

Hi OmeLuuk,

I don't quite get what you meant but if you think the problem has something to do with the TIV 1808 you can always chose a lower TIV in maintain script session form and recompile. I had a problem with fixed/based variables and chosing a lower TIV (in my case 1000) resolved it.
It is not a lasting solution to create an object that uses the backward compatability when the newer tools cause the error. You only buy time to have Infor solve the issue toolswise.

I just suspect what Infor would say would be: It's not a bug, it' a feature :rolleyes:

I just suspect what Infor would say would be: It's not a bug, it' a feature :rolleyes:I would definitly not. 1) It is broken 2) it is reproducible 3) unpredictability of software is never a feature 4) it can be fixed.

I would definitly not. 1) It is broken 2) it is reproducible 3) unpredictability of software is never a feature 4) it can be fixed.A defect has been created, the issue could be reproduced by Infor internally.