Ajesh
8th December 2016, 15:09
My Session is a Type-3 (Multi Occurrence with a View field) , Now at the event of a Checkbox i want the session to be converted to Type-2 with showing all the records and not restricting it to with a particular view field.
Things i tried
Tried to select all Projects instead and re-defined query.extend,hit rebuild.query . But i am not getting expected results.
kishoremeher
8th December 2016, 16:28
try remove.field.from.view()
Ajesh
9th December 2016, 06:59
It can only be used in before.program..
srprks
9th December 2016, 08:35
Hi,
If this solution can meet your expectation:
In your fields on.input event ,you can do one thing, start the session using start session/zoom.to$ and provide there session type MODAL/ MODLESS. and kill your session.
Thanks
vamsi_gujjula
9th December 2016, 13:43
I had almost similar requirement ... a toggle on view fields under specific command but if the sort by option was changed the view fields would in changes type 2 list ( the toggle would work if sort by was changed , but it your case as srprks said you need to restart the session.
-- The comment part would help you in restarting the session and retrieving the key values
declaration:
extern domain tcbool no.view.fields
extern domain tcitem xi.item
before.program:
get.var(parent,"no.view.fields",no.view.fields)
get.var(parent,"xi.item",g.item)
if no.view.fields then
remove.field.from.view("XXsls028.item")
remove.field.from.view("XXsls028.citm")
endif
| zoom.from.all:
| on.entry:
| if not isspace(g.item) then
| ignore.first.event = true
| XXsls028.item = g.item
| execute(find.data)
| endif
group.1:
init.group:
set.checked.command("toggles.view.fields",no.view.fields)
functions:
function extern toggles.view.fields()
{
no.view.fields = not no.view.fields
set.checked.command("toggles.view.fields",no.view.fields)
xi.item = XXsls028.item
|start.session(MODELESS+MULTI_OCC,"XXsls0128m000","XXsls0128m000",")
| end()
}
Ajesh
15th December 2016, 14:15
I tried this restarting the session business. But it really looks terrible.:D
shah_bs
16th December 2016, 00:18
Up until BAAN IV c, any BAAN session has the concept of 'standard program' which controls the 'under the hood' navigations of the screen (in addition to the 'flow' of the session). So, technically, it is necessary to have two different sessions to handle Type 2 and Type 3 navigations. I would assume that this 'foundation' of 'standard program' is also applicable to later versions of BAAN.
Just wondering what sort of functionality would require switching between Type 2 and Type 3.
Ajesh
16th December 2016, 12:48
The requirement is to create a Project Dashboard. Now the user wants all the details by Project Wise. So i have created the view field as Project. And in the detail section, all price lists are there, cost price, sales price etc.
Now he wants to see the details by Project and Parent BOQ wise. Parent BOQ is an entity under project. A Project can have multiple Parent BOQ under it. Now the thing is Parent BOQ is not in the index field. And even if i include it under index field, i would have to restart the session, wouldnt i have to?
vamsi_gujjula
16th December 2016, 12:59
Up until BAAN IV c, any BAAN session has the concept of 'standard program' which controls the 'under the hood' navigations of the screen (in addition to the 'flow' of the session). So, technically, it is necessary to have two different sessions to handle Type 2 and Type 3 navigations. I would assume that this 'foundation' of 'standard program' is also applicable to later versions of BAAN.
Just wondering what sort of functionality would require switching between Type 2 and Type 3.
In my case .. just to upload the data from excel ..using mingle. ( all data - no just the data related to view fields. ) .. so instead of a new session . just had a toggle.
shah_bs
16th December 2016, 17:11
Ajesh
I am not familiar with the Tools system of BAAN LN. They may have better flexibility than BAAN IV c3.
HOWEVER, I would almost think that they could not have disturbed the foundation of the 'standard program' because when a type 3 session is generated (or any type for that matter), the generator EXPECTS the index to be defined at the DATABSE level - that is what allows us to choose how many fields of an index are the view fields and how many in the detail.
(As far as I have understood your requirement) In terms of how I would do this (maybe you have the code and license that will allow to do this):
- Session 1 - type 2 session - display project level data
- sub-session 2 - type 3 session - on selection of the project in session 1, zoom to the sub-session to display the details by BOQ ( assuming that this field is also part of the index at the database level - if not, consider possibility of adding it - but that will need some amount of impact analysis, so something else does not 'break')
mark_h
19th December 2016, 14:34
Actually I did something like this - not quite the same. I used multiple sessions and just made tabs. Each tab represented a different session. It was not pretty and I had to anchor it to the screen and prevent changing form size. Not sure this even qualifies for what you are looking form. In my case it was one main table per form. Some multi-occurrence and some single record.
shah_bs
20th December 2016, 02:46
Wow! This is taking things to the limit!
How did you handle the type 3 form navigation? Or did it just work by standard program logic?
mark_h
20th December 2016, 03:02
Wow! This is taking things to the limit!
How did you handle the type 3 form navigation? Or did it just work by standard program logic?
Works by standard session logic. Each tab is a separate subsession. So basically when you click on a tab it executes another sub-session. Then if you are in that sub-session and click on a different tab - the subsession ends, returns to the main-session and then calls the next sub-session. This beast was designed so you could pick a part - then go to different places and see what it says for inventory and peg. And if necessary you can update a few fields to so the part quantity is balanced across all the tables.
okneb1
20th December 2016, 10:22
Actually I did something like this - not quite the same. I used multiple sessions and just made tabs. Each tab represented a different session. It was not pretty and I had to anchor it to the screen and prevent changing form size. Not sure this even qualifies for what you are looking form. In my case it was one main table per form. Some multi-occurrence and some single record.
Can you share how you achieved this please?
mark_h
20th December 2016, 14:59
So each session has the same 7 forms - so all the session point to the same forms. And yes some are type 1's and some are type 3's. So lets take form 5 - maintain items. Besides the normal session code for its table the parent session code is:
form.5:
before.form:
chld.proc = wait.and.activate("tifix0101s00a")
check.return.from.sessions()
to.form(some.form)
functions:
function check.return.from.sessions()
{
import("some.form",some.form)
import("abrt.code",abrt.code)
if abrt.code>0 then
execute(end.program)
endif
import("zoom.cprj",ticpr951.cprj)
import("zoom.item",ticpr951.item)
import("zoom.mbcs",ticpr951.mbcs)
ticpr951.item = zoom.item
ticpr951.cprj = zoom.cprj
ticpr951.mbcs = zoom.mbcs
ticpr951.trdt = 0
execute(find.data)
}
So now the subsession tifix0101s00a is activated.
form.1:
before.form:
set.exit.variables()
init.form:
to.form(5)
form.2:
before.form:
set.exit.variables()
form.3:
before.form:
set.exit.variables()
form.4:
before.form:
set.exit.variables()
form.5:
init.form:
max_window()
import("ticpr951.item",ticpr951.item)
import("ticpr951.cprj",ticpr951.cprj)
import("ticpr951.mbcs",ticpr951.mbcs)
tiitm001.item = ticpr951.item
execute(find.data)
form.6:
before.form:
set.exit.variables()
form.7:
before.form:
set.exit.variables()
|****************************** field section *********************************
field.ticpr951.item:
before.display:
get.all.totals()
|****************************** choice section ********************************
choice.end.program:
before.choice:
abrt.code = 1
export("abrt.code",abrt.code)
exit()
choice.abort.program:
before.choice:
abrt.code = 2
export("abrt.code",abrt.code)
exit()
functions:
function set.exit.variables()
{
abrt.code = 0
some.form = form.curr
export("some.form",some.form)
export("abrt.code",abrt.code)
zoom.item = ticpr951.item
zoom.cprj = ticpr951.cprj
zoom.mbcs = ticpr951.mbcs
export("zoom.item",zoom.item)
export("zoom.cprj",zoom.cprj)
export("zoom.mbcs",zoom.mbcs)
exit()
}
Now what I did not post is some of the code for the normal session use. Which was not a whole lot - I only allowed certain fields to be modified - mainly quantity fields.
library code -
function extern max_window()
{
long My.Win
My.Win = current.mwindow()
change.object(My.Win,DsNx,0,DsNy,0)
update.object(My.Win)
}
shah_bs
20th December 2016, 16:20
Thank you for the details, Mark.
Like I said - taking it to the limits!