Baanboard.com

Go Back   Baanboard.com > Forum > Baan Quick Support: Functional & Technical > Tools Development

User login

Frontpage Sponsor

Main

Poll
When will you move your ERP to the cloud?
We are on the cloud already!
20%
Next year
8%
from 2-3 years
8%
from 4-5 years
16%
Never!
47%
Total votes: 49

Baanboard at LinkedIn


Reference Content

Reply
 
Thread Tools Display Modes
  #1  
Old 26th April 2016, 16:47
kruyoupatel kruyoupatel is offline
Junior Member
 
Join Date: Aug 2012
Posts: 23
kruyoupatel is on a distinguished road
Baan: BaanIV - DB: informix - OS: ms-win\
Use of "background" keyword in Baan
Baan: Other/Unknown
C/S: None/Unknown

Hello Gurus,

Can anyone tell why BaaN Standard mostly use the keyword "background" within scripts and conditions based on its value.

Checked Help File, says True for Modal session and False for Modeless.

I know difference between Modal and Modeless type of sessions still bit confusing, as what does it conveys with Modal and Modeless.

Somewhere its updating tables or importing data or processing further based on condition of keyword.

Can anyone explain why is it been used. I am sure its not likely for running process in background(not visible to users).
Reply With Quote
  #2  
Old 26th April 2016, 19:25
bdittmar's Avatar
bdittmar bdittmar is offline
Guru
 
Join Date: Apr 2002
Location: Germany, 50.584097,8.544078
Posts: 1,597
bdittmar will become famous soon enough
Baan: 2.2/3.1/4c4/LN6.1 FP6/FP9/HiDox - DB: tbase, ms-sql7, oracle10gV1, 11g - OS: HP-UX, W2K3, SLES
Maybe this helps a little bit

Hello,

BaanERP Programmers Guide

Send feedback about the online Help to Baan Development
Automatic import of variables

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

When you zoom from a main process to a subprocess, in some cases variables are imported automatically.

Case 1
From the main process with main table X you have zoomed to the subprocess with main table Y. Table X has a foreign (cross-reference) key to table Y. For example, X = customer table, Y = currency table. The currency field in the customer table refers to the currency table.

The 4GL engine imports the field(s) from table X and stores them in the primary key fields of table Y.

Consequences for programming in script
In the script of the subsession, only the following needs to be programmed:

if background then
execute(find.data)
(or, sometimes, for type 3 screens: execute(first.set))
else
....
endif

There is no need to adjust the main session in order to import the variables into the subsession.

Case 2
From the main process with main table X, you have zoomed to the subprocess with main table Y. A field in table Y refers to table X. (In most cases, there is an identifying relationship between table X and table Y – for example, order header (table X) and order lines (table Y).) The 4GL engine imports the primary key values from table X and stores them in the corresponding fields of table Y.

Example
Primary key of table X is Order number; primary key of table Y is Order number, position number.

The 4GL engine imports the order number from table X to the corresponding field in table Y. The position number in table Y remains, of course, empty.

Consequences for programming in script
See Case 1 above.

Case 3
From the main process with main table X, you have zoomed to the subprocess with the same main table. (For example, a zoom from 'Maintain Item Data' (type 1) to 'Display Item Data' (type 2 or 3).)

The 4GL engine imports the primary key value from table X for the main process and stores it in the primary key fields of table X for the subprocess.

Consequences for programming in script
See Case 1 above.

Case 4
From the main process with main table X you have zoomed to a subprocess without a main table (for example, a print program). The 4GL engine imports the primary key values of main table X for the main process and stores them in the primary key fields of table X (if available) for the subprocess.

Example
A zoom from 'Maintain Item Data' to 'Print Item Data'. The main table for the main process is tstpi100. The subprocess imports values of tstpi100.cuno and tstpi100.item from the main process and stores them in the fields of the subprocess.

Consequences for programming in script
In many cases, you must reprogram the main process in such a way that the primary key fields of the main table for the subprocess are filled.

Case 5
From the main process without a main table you have zoomed to a subprocess with main table X. The 4GL engine imports the primary key values of table X (if available) for the main process and stores them in the primary key fields of the subprocess's main table.

Example
A zoom from 'Print Item Data' to 'Display Item Data'. The main table for the subprocess is ttstpi100. The 4GL engine tries to import tstpi100.cuno and tstpi100.item from the main process and stores them in the fields of the main table for the subprocess.

Consequences for programming in script
See Case 1 above.

In many cases you must reprogram the main process in such a way that the primary key fields of the main table for the subprocess are filled.

Example
field.item.t:
before.zoom:
tstpi100.cuno = cuno.f
tstpi100.item = item.f

Case 6
From the main process with table X you have zoomed to a subprocess with table Y. There is no relationship between table X and table Y (none has been defined in the data dictionary). The 4GL engine imports the primary key values of table Y for the main process (if available) and stores them in the primary key fields of table Y for the subprocess.

Consequences for programming in script

See Case 1 above.

Often you will have to reprogram the main process in such a way that the primary key fields of the main table for the subprocess are filled.

Example
field.tswoc150.item:
before.zoom:
tstpi100.cuno = tswoc100.cuno
tstpi100.item = tswoc150.item
----------------------
Processes, process groups, and main windows

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

Processes
A process consists of a program object, a date, and a state. A process that has been started can be in any one of the following states:

Running.
The process is in the running queue. It has been scheduled to run, or is ready to be scheduled.

Blocking.
The process is in the blocking queue. It is waiting for input.

Sleeping.
The process is in the sleeping queue. It has been suspended and requires an external action to wake it up again.

Terminating.
The process is in the terminating queue. It has ended but not all its resources have yet been removed.

Each process stores information about the current main window, the current menu, and current character window. Other information about display objects is not directly available to it.

Process groups
A process group is a group of related, interdependent processes. One process is the group leader. Child processes are started by the leader or by one of its children. All processes belong to a process group.

The following are some of the characteristics of process groups:

Each process group has its own event queue. Events are sent to the process group, not to individual processes.
When one process within a group starts a child process, the child process is automatically placed in the same process group as its parent. However, you can use the function set.pgrp() to place the process in a different process group.
When a process is killed or ended, its parent is automatically awakened, unless the parent and child are in different groups.
You use the grab.mwindow() function to set the process group to which a main window sends its events. After calling this function, all events that occur in the main window are sent to the specified process group.
Main windows
A main window acts as the frame window for both sessions and 3GL applications. It is used for starting processes and for creating graphical and character windows. It is not used directly for handling user input or displaying program output. Usually, a main window consists of a border, title bar, menu bar, status area, control menu box, sizing controls, and a work area. The objects used by an application for user interaction are created within the work area of a main window and are managed by that main window.

Each process can have zero, one, or more main windows.

Process groups and main windows
Process groups and main windows are used:

to ensure unambiguity of input focus
to keep related processes dependent
to enable parent and child processes to be independent of each other
Unambiguity of input focus
To ensure that there is never any ambiguity as to where the events generated by a particular window are sent, when you create a main window, you define a single process group to which that main window sends its events. You do this with the grab.mwindow() function. After calling this function for a main window, all events that occur in that window are sent to the specified process group. In principle, there is only one running process in a process group at any time; so the events are sent to that process.

In principle, each process could have its own event queue. However, there are a number of situations where this would cause problems. For example:

When the input focus is on an input field and the user zooms to another process to select a value. In this case, the parent process is moved to the sleeping queue and will be awakened when the child process ends.
However, if the user types in the input field after the zoom process has started but before the zoom process has created its own windows, the characters typed are sent to the sleeping process and not to the zoom process for which they were intended. When the windows of the zoom process appear, the user must then restart the selection. However, when the zoom process exits, the characters sent to the parent process are displayed in the input field and not those entered in the zoom process. This is because, when awakened, the parent process finds those characters in its process queue.

A similar problem can arise when a uses ends a number of nested processes by repeatedly pressing the EXIT key and also when processes are synchronized by using bucket functions.
These problems are avoided by enabling related, interdependent processes to share the same process group (and so the same event queue).

Keeping related processes dependent
When a process is started by the functions activate(), act.and.sleep(), or wait.and.activate(), by default the new process inherits the process group and main window of its parent. The parent process is moved to the sleeping queue will be awakened automatically when the child process ends.

The following diagram illustrates this.

.

A process with the same ID as its process group is referred to as the group leader. For the group leader, the predefined variable background is set to FALSE, For child processes, this variable is set to TRUE.

A process group keeps track of the number of processes that belong to it. When no processes remain in the group, the group is automatically destroyed. You can destroy all processes in a particular group simultaneously by calling kill.pgrp().

Making related processes independent
When a process starts a child process, by default the child process inherits the process group and main window of its parent, and the parent is suspended until the child exits. However, it is possible to create a new process group and main window for the child process and so keep the parent and child processes independent. The following diagram illustrates this.

.

The code for disconnecting a child process from its parent can be included either in the parent process or in the child process. In the following example, it is included in the parent process.

old.mwindow = current.mwindow()
new.mwindow = create.mwindow( title, mode, flags)
change.mwindow( new.mwindow )
child.pid = act.and.sleep( program.name, arglist )
if child.pid then
set.pgrp( child.pid, child.pid )
grab.mwidow( new.mwindow, child.pid )
reactivate( child.pid )
endif
change.mwindow ( old.mwindow )
destroy.mwindow( new.mwindow )

In this example, the parent process first creates a new main window for the child process. It then starts the child process and calls set.pgrp() to place the child process in a different process group. By specifying the same ID for the process and the process group in the set.pgrp() call, a new process group is automatically created with the same ID as the process. The process becomes the leader of the new process group. The parent process then calls grab.mwindow() to link the new process group to the new main window.

In this example, it is important to start the child process with act.and.sleep() and to reactivate the process only after it has been placed in the new process group. If the process is started with activate(), and a context switch occurs immediately after the child process is started, then the process would be scheduled with the incorrect process group.

Note that if a process is moved to another process group, it will be impossible to switch it back to the original group if that group is destroyed in the meantime.


Regards
__________________
//Bernd
Reply With Quote
  #3  
Old 27th April 2016, 07:03
bhushanchanda's Avatar
bhushanchanda bhushanchanda is offline
Guru
 
Join Date: Sep 2012
Location: India
Posts: 2,190
bhushanchanda has a spectacular aura aboutbhushanchanda has a spectacular aura aboutbhushanchanda has a spectacular aura about
Baan: LN FP 1-9, 10.4, a little bit of Baan IV - DB: SQL Server 2008, Oracle - OS: Windows Server 2008 R2, Unix
Hi,

You can go through the following threads to see how and where it can be used -

Thread 1
Thread 2
Thread 3
Thread 4

Its basically, when a program A calls program B and Program A is blocked until B is executed. In this situation the background is set to 1 in Program B.

Here Program A/B can be session or even 3GL Scripts(wait.and.activate())
__________________
Regards,

Bhushan

Unless you try to do something beyond what you have already mastered, you will never grow!
Reply With Quote
Sponsored Links
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Baan Tools Administrator Muhammad Ali Jobs and Resumes 0 27th June 2007 09:49
Senior Baan Administrator OneNeck IT Svcs Jobs and Resumes 0 15th February 2007 18:11
Not authorized to run as user baan positive Tools Administration & Installation 7 29th June 2004 08:56


All times are GMT +2. The time now is 21:08.


©2001-2017 - Baanboard.com - Baanforums.com