Re: (forte-users) workspace-open [Virus checked by NAINetshield]

---------------------- Forwarded by Richard Stobart/ExternalUser/GB/WCG on
02/05/2000 13:51 ---------------------------
From: Richard Stobart Willis
2 May 2000 13:49 GDT
To: "Aissa Amazzal" <aamazzalaxialog.fr>
cc:
bcc:
Subject: Re: (forte-users) workspace-open [Virus checked by NAI Netshield]
(Document link: Database 'Richard Stobart', View '($Sent)')
Aissa,
Run fscript distributed and do an unlockworkspace.
fscript > help unlockworkspace
UnlockWorkspace <workspaceName> [<workspacePassword>]
Force an unlocking of 'workspaceName'. This will release the repository
locks associated with the specified workspace. Use this command ONLY if
the workspace is not in use, and some unusual error condition has left the
repository server in a bad state.
Regards
Richard
"Aissa Amazzal" <aamazzalaxialog.fr> on 02/05/2000 13:45:36
To: forte-userslists.xpedior.com
cc:
bcc: Richard Stobart/ExternalUser/GB/WCG
Subject: (forte-users) workspace-open [Virus checked by NAI Netshield]
Hi;
I work on my workspace and there is sudenly a rupture of courant. After, I
can't open my workspace.I must shutdown the server before working. Is there
another solution ?
Thanks

Similar Messages

RE: (forte-users) Check this ( -----THIS MESSAGE WASA VIRUS!!!!!)

The previous message (Check this) is a known virus.
(Either that or the sender is emulating it.
Either way, do not open the attachment as you will not have "fun" at all.
Delete the message immediately.
Of course, if I am wrong then I am an idiot!
Don't take the chance.
-----Original Message-----
From: Slabbert, Etienne [mailto:etiennemds.co.za]
Sent: Friday, 18 February 2000 0:12
To: forte-userslists.xpedior.com
Subject: (forte-users) Check this
Have fun with these links.
Bye.

Il suffit de mettre les BTD/BTX sur un drive réseau (net use X:
\\server\share_point),
puis d'installer des icônes pour les clients: ftexec -fi bt:x:\MyApp.
Pour que les noeuds ne s'auto-enregistrent pas, peut-être mettre un password
Ou bien définir les noeuds comme un 'groupe' et donc seul le groupe est
connu.
Si mettre le mot de passe suffit pas, et si vraiment le model node gêne,
alors il
faut un autre environment manager.
I think that to avoid install, the software could be located on a shared
drive,
and users linking to it through running 'ftexec' or directly the compiled
binaries.
For nodes not to appear in the environment as nodes, they could be defined
as members
of a model node '(which then would be in the environmnet)'
Putting a password in the environment could prevent nodes to be registered
there, but
might prevent the apps from being executed.
Cheers,
j-paul gabrielli
Sema DTS
-----Message d'origine-----
De: Thomas Felix [mailto:tfelixaxialog.fr]
Date: mardi 2 mai 2000 14:14
À: forte-userslists.xpedior.com
Objet: (forte-users)
bonjour a tous
je souhaites installer une application distribuée sur des postes clients.
Y'a t'il moyen de ne pas installer les noeuds de ces postes clients sur l'
active environnement lié au développement et si oui comment?
hi
I would like to install an application on clients workstation
Can i install this nodes in a different Active environnement than this one
that we use for the developpement ?
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

PC Users are unable to check Outlook while my (mac) Mail is open

Ever since I upgraded to 10.4, whenever I have my Mail application open, the PC users are unable to check their IMAP mail through Outlook. The PC Users and myself are all using different accounts, but are checking the same server.
At first, this seemed like it was a coincidence... but then I shut my powerbook and they could check their again. I have to use a web mail client to check my email when I am on the network at work.
Any ideas to resolve this issue? Mail is set to check every 5 minutes.

AA8 and AA9 allow Reader Rights so the user can save the form. This is restricted by the license to 500 uses. In the long run, the only advantage of the Reader Rights is for your users, not for you. You can always import the data into the form and have the same result as they had in the form. It is not necessary to transmit the full form to you, only the data. If you were developing a web form that would likely exceed the 500 uses, you would have to negotiate a price with Adobe for Reader Rights (thousands of $$ should be expected).
If saving is important in a company environment, not online, then you may want to read the EULA carefully as to the exceptions. You will still have to have at least AA8.
I guess the printing problem was answered.

Access 2010 checking if a user has opened a zipped rather than expanded database

Is there a property or method that can be used to detect/ check if a user has opened a zipped copy of a database?
I distribute a zipped copy of a database and expect users to extract it before using it but some times a user simply opens the zipped copy and later encounters problems. I would like to display a message notifying the user that they must first expand the
zipped file before opening the database.
phil kelly

Maybe this will help.
Option Compare Database
Option Explicit
'See MSDN for more constants: http://msdn2.microsoft.com/en-us/library/ms839432.aspx
Const CSIDL_APPDATA = &H16
Const CSIDL_DESKTOP = &H0
Const CSIDL_PROGRAMS = &H2
Const CSIDL_CONTROLS = &H3
Const CSIDL_PRINTERS = &H4
Const CSIDL_PERSONAL = &H5
Const CSIDL_FAVORITES = &H6
Const CSIDL_STARTUP = &H7
Const CSIDL_RECENT = &H8
Const CSIDL_SENDTO = &H9
Const CSIDL_BITBUCKET = &HA
Const CSIDL_STARTMENU = &HB
Const CSIDL_DESKTOPDIRECTORY = &H10
Const CSIDL_DRIVES = &H11
Const CSIDL_NETWORK = &H12
Const CSIDL_NETHOOD = &H13
Const CSIDL_FONTS = &H14
Const CSIDL_TEMPLATES = &H15
Const MAX_PATH = 260
Private Type SHITEMID
cb As Long
abID As Byte
End Type
Private Type ITEMIDLIST
mkid As SHITEMID
End Type
Private Declare Function SHGetSpecialFolderLocation Lib "shell32.dll" (ByVal hwndOwner As Long, ByVal nFolder As Long, pidl As ITEMIDLIST) As Long
Private Declare Function SHGetPathFromIDList Lib "shell32.dll" Alias "SHGetPathFromIDListA" (ByVal pidl As Long, ByVal pszPath As String) As Long
Public Function GetProgramFilesFolder() As String
Const PROGRAM_FILES = &H26&
Dim objShell As Object
Dim objFolder As Object
Dim objFolderItem As Object
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(PROGRAM_FILES)
Set objFolderItem = objFolder.Self
Debug.Print objFolderItem.Path
End Function
Private Function GetSpecialfolder(CSIDL As Long) As String
Dim r As Long
Dim IDL As ITEMIDLIST
Dim sPath As String
'Get the special folder
r = SHGetSpecialFolderLocation(100, CSIDL, IDL)
If r = 0 Then
'Create a buffer
sPath$ = Space$(512)
'Get the sPath from the IDList
r = SHGetPathFromIDList(ByVal IDL.mkid.cb, ByVal sPath$)
'Remove the unnecessary chr$(0)'s
GetSpecialfolder = Left$(sPath, InStr(sPath, Chr$(0)) - 1)
Exit Function
End If
GetSpecialfolder = ""
End Function
Public Sub PrintSpecFolderPaths()
'KPD-Team 1998
'URL: http://www.allapi.net/
'E-Mail: [email protected]
'Print the folders to the form
Debug.Print "Start menu folder: " & GetSpecialfolder(CSIDL_STARTMENU)
Debug.Print "Favorites folder: " & GetSpecialfolder(CSIDL_FAVORITES)
Debug.Print "Programs folder: " & GetSpecialfolder(CSIDL_PROGRAMS)
Debug.Print "Desktop folder: " & GetSpecialfolder(CSIDL_DESKTOP)
Debug.Print "My Docs folder: " & GetSpecialfolder(CSIDL_PERSONAL)
End Sub
Bill Mosca
www.thatlldoit.com
http://tech.groups.yahoo.com/group/MS_Access_Professionals

RE: (forte-users) [UNIX] "Too many open files" 3.0.M2question

Actually, the stuff works in interpreted mode.
It's only when having the server partition compiled that this happen.
j-p
-----Message d'origine-----
De: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Date: lundi 25 septembre 2000 17:13
À: 'Jean-Paul.Gabriellisema.fr'
Cc: Forte-userslists.xpedior.com
Objet: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
see Technote 10981
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 11:02 AM
To: zeForte-users
Subject: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
Hi,
running a server partition that reads a configuration file,
and apparently doen't close it after, I have that exception:
SYSTEM ERROR: System Error: Too many open files, opening '....'with mode
'r'
Class: qqos_FileResourceException
1) Is there such a limit, or does this rely only on the OS one ?
2) How is this error not trapped, as I only got itinteractively, whereas
my server log does a exception trap/segmentation fault,
thanlks
j-p
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe,send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Hi Jean-Paul,
As described in the Technote 10981 some Forte programs (Nodemanager and
router) handle correct the high-file descriptor-use problem. It is possible
that Forte interpreter do it correct too.
Zenon
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 12:11 PM
To: Adamek, Zenon
Cc: Forte-userslists.xpedior.com
Subject: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2
question
Actually, the stuff works in interpreted mode.
It's only when having the server partition compiled that this happen.
j-p
-----Message d'origine-----
De: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Date: lundi 25 septembre 2000 17:13
À: 'Jean-Paul.Gabriellisema.fr'
Cc: Forte-userslists.xpedior.com
Objet: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
see Technote 10981
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 11:02 AM
To: zeForte-users
Subject: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
Hi,
running a server partition that reads a configuration file,
and apparently doen't close it after, I have that exception:
SYSTEM ERROR: System Error: Too many open files, opening '....'with mode
'r'
Class: qqos_FileResourceException
1) Is there such a limit, or does this rely only on the OS one ?
2) How is this error not trapped, as I only got itinteractively, whereas
my server log does a exception trap/segmentation fault,
thanlks
j-p
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe,send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
>
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) FW: (forte-users)

Hi there
Thanks very much for the solution - just wanted to let you know . We
implemented the design that technote 11378 suggested .
It worked .
Thanks very much
Cheers
Jen
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, 20 March, 2001 9:21 PM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users) FW: (forte-users)
Hi David,
The problem is that the SO uses an attribute of its class ACBAccount as
the ObjectReference pointer. SO is not a stateless object. The possible
scenario before crash can be that client A and B calls SO at the same
time. A's thread creates ACBAccount gets the ObjectReference. At this
point B's thread is activated, does the same as A creates new
ObjectReference. Probably the next switch between A and B will be in the
Connect() (B should wait for OLE server). If A is reactivated it doesn't
get the original own reference but the B's reference. It can cause the
crash and means that a thread can use reference created in some other
thread.
Regards,
Zenon
-----Original Message-----
From: David McPaul [SMTP:dmcpaullumley.com.au]
Sent: Monday, March 19, 2001 11:52 PM
To: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Jenni,
As Zenon has pointed out, technote 11378 talks about problems that
can occur if the calls made to an OLE object are not from within the same
thread the OLE object was created in. It goes on to show a design to
avoid
this.
However, the code you have given DOES communicate to the OLE object
in the same thread as it was created. So the problem as I see it is more
likely to be that the OLE object is not being garbage collected. Although
you do explicitly NIL out the ACBAccount object there is a technote 12453
that deals with the need to set the ObjectReference of CDispatch objects
to
NIL to allow the OLE object to be completely reclaimed by the garbage
collector. Failure to do so when using code that creates a new OLE object
every time you ask for an account validation will eventually run the
partition out of memory.
As pointed out in a previous post you can also increase
FORTE_STACK_SIZE but this will delay the problem not correct it.
Rather than create the connection each time you may want to think
about redesigning the method as shown in tech note 11378.
Cheers
David
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, March 20, 2001 5:05 AM
To: 'Els, Jenni'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Hi Jenni,
The most important issue by designing an OLE connection between a Forte
server partition and an OLE component is taking into account that an OLE
object can be referenced from the NT thread in Forte partition that it was
created in. It is the reason that you have no problems with your mini-app
in
single-threaded version.
This problem is discussed in the Technote 11378. You can find a workaround
for your problem there, too.
Regards,
Zenon
-----Original Message-----
From: Els, Jenni [SMTP:JElsnbs.co.za]
Sent: Monday, March 19, 2001 2:28 AM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users)
Hi there
We have this situation
We are calling a Service Object (in the server partition) from ourclient
partition.This service object calls a method which calls a DLLregistered
on our server (VB code) . This VB code access a database on anotherserver
.(DSN set up on our server ).The database is sql server .
We are having the problem where for about 3 hours in the morning , the
system works perfectly. We then get a segmentation violation on this
partition . When we run interpreted we can see that this is an OLEinvoked
exception. The partition does not always show as offline in econsole
and
because it does not , we cannot 'online' another . We cannot take the
entire app down as everything hangs . Eventually our technical depthas
to
down the server
We set up a mini-app looping through and calling the DLL to simulate
the
problem . It worked fine. When we put another asynchronous task in the
method to call the service object , it erred quite soon. We thencreate
an
attribute of type mutex and locked using that. The mini-app worked.
However our app in development eventually hanged (without the
partition
coming though) .
The service Object is an environment visible service object in asingle
(non-replicated partition) . It has a dialog duration = session .
In the project is
ACB : ACBObject
ACBObject : CDispatch (shared = disallowed , distributed =
disallowed, transactional = disallowed, monitored = allowed)
ACBValidator : Object (shared = allowed , distributed =allowed,
transactional = disallowed, monitored = disallowed)
ACBVaidatorSO : ACBValidator
In this method we have this code to call the DLL
self.ACBAccount = new;
self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
8CEA0}');
pErrorMessage = new;
acbaccount.BankCode = pBankCode.value;
acbaccount.BranchCode = pBranchCode.value;
at : VariantI2 = new;
at.Value = pAccountType.Value;
acbaccount.AccountType = at.Value;
acbaccount.AccountNo = pAccountNo.value;
begin
acbaccount.Connect();
exception
when e : GenericException do
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error connecting to the database');
raise ex;
end;
begin
err : i2 = acbaccount.ValidateAccount();
if err != 0 then
pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
acbaccount.Disconnect();
return false;
else
pErrorMessage.SetValue('The account is
valid!!');
acbaccount.Disconnect();
self.ACBAccount = NIL ;
return true;
end if;
exception
when e : GenericException do
acbaccount.Disconnect();
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error Validating the account');
Task.ErrorMgr.AddError(ex);
task.errormgr.ShowErrors();
raise e;
end;
exception
when e : GenericException do
acbaccount.Disconnect();
Task.ErrorMgr.ShowErrors();
raise e;
If anybody has any suggestions , they would be most welcome
Thanks very much
Cheers
Jenni Els************************************************************************Th
is e-mail is intended for the use of the individual or entity named above
and may contain information that is confidential and privileged. If you
are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this e-mail is strictly
prohibited. If you have received this e-mail in error, please notify us
immediately at helpdesklumley.com.au and destroy the original message.
While this mail and any attachments have been scanned for common computer
viruses and found to be virus free, we recommend you also perform your own
virus checking processes before opening any attachments.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com--
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
WARNING:
Any unauthorised use or interception of this email is illegal. If this email
is not intended for you, you may not copy, distribute nor disclose the
contents to anyone. Save for bona fide company matters, the BoE Group does
not accept any responsibility for the opinions expressed in this email.
For further details please see: http://www.nbs.co.za/emaildisclaim.htm

Hi there
Thanks very much for the solution - just wanted to let you know . We
implemented the design that technote 11378 suggested .
It worked .
Thanks very much
Cheers
Jen
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, 20 March, 2001 9:21 PM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users) FW: (forte-users)
Hi David,
The problem is that the SO uses an attribute of its class ACBAccount as
the ObjectReference pointer. SO is not a stateless object. The possible
scenario before crash can be that client A and B calls SO at the same
time. A's thread creates ACBAccount gets the ObjectReference. At this
point B's thread is activated, does the same as A creates new
ObjectReference. Probably the next switch between A and B will be in the
Connect() (B should wait for OLE server). If A is reactivated it doesn't
get the original own reference but the B's reference. It can cause the
crash and means that a thread can use reference created in some other
thread.
Regards,
Zenon
-----Original Message-----
From: David McPaul [SMTP:dmcpaullumley.com.au]
Sent: Monday, March 19, 2001 11:52 PM
To: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Jenni,
As Zenon has pointed out, technote 11378 talks about problems that
can occur if the calls made to an OLE object are not from within the same
thread the OLE object was created in. It goes on to show a design to
avoid
this.
However, the code you have given DOES communicate to the OLE object
in the same thread as it was created. So the problem as I see it is more
likely to be that the OLE object is not being garbage collected. Although
you do explicitly NIL out the ACBAccount object there is a technote 12453
that deals with the need to set the ObjectReference of CDispatch objects
to
NIL to allow the OLE object to be completely reclaimed by the garbage
collector. Failure to do so when using code that creates a new OLE object
every time you ask for an account validation will eventually run the
partition out of memory.
As pointed out in a previous post you can also increase
FORTE_STACK_SIZE but this will delay the problem not correct it.
Rather than create the connection each time you may want to think
about redesigning the method as shown in tech note 11378.
Cheers
David
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, March 20, 2001 5:05 AM
To: 'Els, Jenni'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Hi Jenni,
The most important issue by designing an OLE connection between a Forte
server partition and an OLE component is taking into account that an OLE
object can be referenced from the NT thread in Forte partition that it was
created in. It is the reason that you have no problems with your mini-app
in
single-threaded version.
This problem is discussed in the Technote 11378. You can find a workaround
for your problem there, too.
Regards,
Zenon
-----Original Message-----
From: Els, Jenni [SMTP:JElsnbs.co.za]
Sent: Monday, March 19, 2001 2:28 AM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users)
Hi there
We have this situation
We are calling a Service Object (in the server partition) from ourclient
partition.This service object calls a method which calls a DLLregistered
on our server (VB code) . This VB code access a database on anotherserver
.(DSN set up on our server ).The database is sql server .
We are having the problem where for about 3 hours in the morning , the
system works perfectly. We then get a segmentation violation on this
partition . When we run interpreted we can see that this is an OLEinvoked
exception. The partition does not always show as offline in econsole
and
because it does not , we cannot 'online' another . We cannot take the
entire app down as everything hangs . Eventually our technical depthas
to
down the server
We set up a mini-app looping through and calling the DLL to simulate
the
problem . It worked fine. When we put another asynchronous task in the
method to call the service object , it erred quite soon. We thencreate
an
attribute of type mutex and locked using that. The mini-app worked.
However our app in development eventually hanged (without the
partition
coming though) .
The service Object is an environment visible service object in asingle
(non-replicated partition) . It has a dialog duration = session .
In the project is
ACB : ACBObject
ACBObject : CDispatch (shared = disallowed , distributed =
disallowed, transactional = disallowed, monitored = allowed)
ACBValidator : Object (shared = allowed , distributed =allowed,
transactional = disallowed, monitored = disallowed)
ACBVaidatorSO : ACBValidator
In this method we have this code to call the DLL
self.ACBAccount = new;
self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
8CEA0}');
pErrorMessage = new;
acbaccount.BankCode = pBankCode.value;
acbaccount.BranchCode = pBranchCode.value;
at : VariantI2 = new;
at.Value = pAccountType.Value;
acbaccount.AccountType = at.Value;
acbaccount.AccountNo = pAccountNo.value;
begin
acbaccount.Connect();
exception
when e : GenericException do
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error connecting to the database');
raise ex;
end;
begin
err : i2 = acbaccount.ValidateAccount();
if err != 0 then
pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
acbaccount.Disconnect();
return false;
else
pErrorMessage.SetValue('The account is
valid!!');
acbaccount.Disconnect();
self.ACBAccount = NIL ;
return true;
end if;
exception
when e : GenericException do
acbaccount.Disconnect();
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error Validating the account');
Task.ErrorMgr.AddError(ex);
task.errormgr.ShowErrors();
raise e;
end;
exception
when e : GenericException do
acbaccount.Disconnect();
Task.ErrorMgr.ShowErrors();
raise e;
If anybody has any suggestions , they would be most welcome
Thanks very much
Cheers
Jenni Els************************************************************************Th
is e-mail is intended for the use of the individual or entity named above
and may contain information that is confidential and privileged. If you
are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this e-mail is strictly
prohibited. If you have received this e-mail in error, please notify us
immediately at helpdesklumley.com.au and destroy the original message.
While this mail and any attachments have been scanned for common computer
viruses and found to be virus free, we recommend you also perform your own
virus checking processes before opening any attachments.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com--
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
WARNING:
Any unauthorised use or interception of this email is illegal. If this email
is not intended for you, you may not copy, distribute nor disclose the
contents to anyone. Save for bona fide company matters, the BoE Group does
not accept any responsibility for the opinions expressed in this email.
For further details please see: http://www.nbs.co.za/emaildisclaim.htm

RE: (forte-users) Node Installed Libraries

If you use Forte, the solution is to patch compcomp, or add a 'post-distrib'
script.
compcomp:
replace the -L/path/file by -L/path -l:file
Add -Wl,+s in link command
post-distrib:
# Enable SHLIB_PATH
for all binaries,
chatr +s enable $bin
done
# Enable dyunamic libs for all static
Libs=$(cahtr $bin | grep ^static)
for aLib in $Libs ; do
chatr $bin +s enable -l $aLib
done
cheers
j-paul
-----Message d'origine-----
De: kelsey.petrychynsasktel.sk.ca
[mailto:kelsey.petrychynsasktel.sk.ca]
Date: lundi 18 septembre 2000 18:36
À: David McPaul; Rottier.Pascalpmintl.ch
Cc: forte-userslists.xpedior.com
Objet: RE: (forte-users) Node Installed Libraries
Libraries have been a sore point with us too....
When we build something that uses a user created or third party
library the
explicit directory path is hard-coded into the build.
So when you deploy the application to a different machine there
is much grief
because the build can't find the library.
We got around this by "fooling" the build. We used directory
creation and soft
links in Unix so that the library appears to be in the same
directory on both machines.
I think this is called Static vs. Dynamic Libraries. We've talked
to Forte last
year about this and they indicated that this will be a
future enhancement. Don't hold your breath though.....
David McPaul <dmcpaullumley.com.au> on 09/17/2000 07:14:13 PM
To: "'Rottier, Pascal'" <Rottier.Pascalpmintl.ch>, "'Forte Users'"
<forte-userslists.xpedior.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: RE: (forte-users) Node Installed Libraries
Hi,
We build here against a standard environment (1 NT server, 1 NT
modal node, 1 95 modal node)
I have noticed that forte is very picky about where it deploys
compiled partitions (and thus libraries). Basically if you
didn't make your
distribution against the environment you are installing on then
the compiled
partitions don't install and you will need to reconfigure the
application by
moving your partitions and libraries to the nodes that they should be.
Now I expected that would be the case between different
architectures (UNIX/NT) but I think forte expects you to compile against
each machine you want to install on.
Not much help I know.
Cheers
David
-----Original Message-----
From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
Sent: Saturday, September 16, 2000 12:59 AM
To: 'Forte Users'
Subject: (forte-users) Node Installed Libraries
Hi guys,
When you deploy a library using Forte, if automatically updates the
"Installed Libraries" list of the target node. However, not always. My
question is, why? What property determines if a library should appear in
this list or not. Of course, you can always add or remove it manually. But
why doesn't it work the same automatically for all libraries.
Pascal Rottier
Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
******This
e-mail is intended for the use of the individual or entity named
above and may
contain information that is confidential and privileged. If you
are not the
intended recipient, you are hereby notified that any
dissemination, distribution
or copying of this e-mail is strictly prohibited. If you have
received this
e-mail in error, please notify us immediately at
helpdesklumley.com.au and
destroy the original message. While this mail and any
attachments have been
scanned for common computer viruses and found to be virus free,
we recommend you
also perform your own virus checking processes before opening any
attachments.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

If you use Forte, the solution is to patch compcomp, or add a 'post-distrib'
script.
compcomp:
replace the -L/path/file by -L/path -l:file
Add -Wl,+s in link command
post-distrib:
# Enable SHLIB_PATH
for all binaries,
chatr +s enable $bin
done
# Enable dyunamic libs for all static
Libs=$(cahtr $bin | grep ^static)
for aLib in $Libs ; do
chatr $bin +s enable -l $aLib
done
cheers
j-paul
-----Message d'origine-----
De: kelsey.petrychynsasktel.sk.ca
[mailto:kelsey.petrychynsasktel.sk.ca]
Date: lundi 18 septembre 2000 18:36
À: David McPaul; Rottier.Pascalpmintl.ch
Cc: forte-userslists.xpedior.com
Objet: RE: (forte-users) Node Installed Libraries
Libraries have been a sore point with us too....
When we build something that uses a user created or third party
library the
explicit directory path is hard-coded into the build.
So when you deploy the application to a different machine there
is much grief
because the build can't find the library.
We got around this by "fooling" the build. We used directory
creation and soft
links in Unix so that the library appears to be in the same
directory on both machines.
I think this is called Static vs. Dynamic Libraries. We've talked
to Forte last
year about this and they indicated that this will be a
future enhancement. Don't hold your breath though.....
David McPaul <dmcpaullumley.com.au> on 09/17/2000 07:14:13 PM
To: "'Rottier, Pascal'" <Rottier.Pascalpmintl.ch>, "'Forte Users'"
<forte-userslists.xpedior.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: RE: (forte-users) Node Installed Libraries
Hi,
We build here against a standard environment (1 NT server, 1 NT
modal node, 1 95 modal node)
I have noticed that forte is very picky about where it deploys
compiled partitions (and thus libraries). Basically if you
didn't make your
distribution against the environment you are installing on then
the compiled
partitions don't install and you will need to reconfigure the
application by
moving your partitions and libraries to the nodes that they should be.
Now I expected that would be the case between different
architectures (UNIX/NT) but I think forte expects you to compile against
each machine you want to install on.
Not much help I know.
Cheers
David
-----Original Message-----
From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
Sent: Saturday, September 16, 2000 12:59 AM
To: 'Forte Users'
Subject: (forte-users) Node Installed Libraries
Hi guys,
When you deploy a library using Forte, if automatically updates the
"Installed Libraries" list of the target node. However, not always. My
question is, why? What property determines if a library should appear in
this list or not. Of course, you can always add or remove it manually. But
why doesn't it work the same automatically for all libraries.
Pascal Rottier
Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
******This
e-mail is intended for the use of the individual or entity named
above and may
contain information that is confidential and privileged. If you
are not the
intended recipient, you are hereby notified that any
dissemination, distribution
or copying of this e-mail is strictly prohibited. If you have
received this
e-mail in error, please notify us immediately at
helpdesklumley.com.au and
destroy the original message. While this mail and any
attachments have been
scanned for common computer viruses and found to be virus free,
we recommend you
also perform your own virus checking processes before opening any
attachments.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) Screen Scraping

I think they changed their name since Conextions at least 2 times. Try this
web site:
http://www.wrq.com/products/apptrieve/
noro
-----Original Message-----
From: Denver Jobs [mailto:fortejobsindenveryahoo.com]
Sent: Monday, November 13, 2000 8:31 AM
To: forte-userslists.xpedior.com
Subject: Re: (forte-users) Screen Scraping
Michael,
We use Conextions for screen scraping from the
mainframe - and I believe that it is supported by
Forte. I tried checking their website to see if they
offered it for Unix, but their site was down.?
Some others you may want to check with are Pixel
Science Technology or FileFrameVX. I also saw an
interesting article on Eclipse Host Integration
Server, but it appears they've shut down and
transferred their knowledge base to a company called
eNucleus.
--- Michael Strauss <mstraussmazda.com.au> wrote:
Has anyone performed any screen scraping either
directly from Forte
(sockets) or via C wrapping? I would be very
interested to hear some
feedback and pointers. I want to scrape from my
Unix server and provide the
scraped data to my GUI client (Win).
TIA
Michael Strauss
>
>
Mazda Australia takes every precaution to ensure
email messages
are virus free.
For extra protection you should virus scan this
message yourself.
>
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
http://calendar.yahoo.com/
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Hi Jean-Paul,
As described in the Technote 10981 some Forte programs (Nodemanager and
router) handle correct the high-file descriptor-use problem. It is possible
that Forte interpreter do it correct too.
Zenon
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 12:11 PM
To: Adamek, Zenon
Cc: Forte-userslists.xpedior.com
Subject: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2
question
Actually, the stuff works in interpreted mode.
It's only when having the server partition compiled that this happen.
j-p
-----Message d'origine-----
De: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Date: lundi 25 septembre 2000 17:13
À: 'Jean-Paul.Gabriellisema.fr'
Cc: Forte-userslists.xpedior.com
Objet: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
see Technote 10981
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 11:02 AM
To: zeForte-users
Subject: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
Hi,
running a server partition that reads a configuration file,
and apparently doen't close it after, I have that exception:
SYSTEM ERROR: System Error: Too many open files, opening '....'with mode
'r'
Class: qqos_FileResourceException
1) Is there such a limit, or does this rely only on the OS one ?
2) How is this error not trapped, as I only got itinteractively, whereas
my server log does a exception trap/segmentation fault,
thanlks
j-p
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe,send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
>
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) 3J= 3M new to me error

Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) RE: Forte 3 vs Java --Productivity

I think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

I think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Re: (forte-users) access violation caught in debugmode

Eric,
There has been a problem with Forte debug mode for sometime now when the app
is silent. If you attempt to inspect the variables when the app is in the
'silent' mode, i.e., waiting on an event loop for a user input or a system
event, then you get the "Access violation caught ..." exception message and
the workspace including the launch server crashes.
If you are getting this problem in the 'step-through' mode, you should look
at the lauch server immediately after you get the exception before
everything disappears. There could be a stack backtrace due to some illegal
reference. We have faced a similar situation before but the error appeared
both in the 'debug' and 'run' modes.
Hope this helps.
Braja K Chattaraj.
From: Eric Decossaux <[email protected]>
To: forte mailing <[email protected]>
Subject: (forte-users) access violation caught in debug mode
Date: Thu, 23 Sep 1999 17:31:39 +0200
Hello,
I have a problem using Forte in debug mode. If I run my program on my NT
machine from the partition workshop (distributed run), the program works
fine except that some object does not display what I'm expecting. So I
want to use the debug mode to inspect the objets of this window. When I
choose the "local variables" option to see the content of my window, I
have a "access violation caught" and forte disappears. If I just let my
program run without choosing this option, everything is the same than
with the distributed run.
Does somebody have an idea what to look for ? I really want to look the
inside the attributes of this window.
We recently upgraded from release 30G2 to release 30L2. Could it be the
problem ?
Eric Decossaux
Cliniques Universitaires St Luc
Informatique des Laboratoires
av Hippocrate 10 / 1730
1200 Bruxelles
+32+2+764 17 53
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Eric,
Another possibility has to do with the repository. You said you recently
migrated 30G2 to release 30L2.
Many strange problems have been traced to release migrations with old
repositories. If the repository was properly migrated another thing you can try
is to export the project(s) to PEX files, delete them from the repository, and
then re-import. I know this can be time consuming but I have solved more than
one unexplained problem in the IDE by doing it.
---------------------- Forwarded by Charlie Shell/Bsg/MetLife/US on 09/23/99
01:19 PM ---------------------------
"Ajith Kallambella" <[email protected]> on 09/23/99 12:08:54 PM
To: [email protected], [email protected]
cc: (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: Re: (forte-users) access violation caught in debug mode
Eric,
Sometimes( 90% ) you can solve this problem by
checking out the class that is causing the crash
and force-compiling it.
If it doesn't help, run through this checklist.
1. Do you have enough memory resources.?
2. Is the object you are inspecting held in a lock ?
( mutex, transaction lock etc )
3. Does it work when you wait for sometime at the
breakpoint before inspecting the values? I mean
are you interrupting some process thread?
4. Does it work if you log the attributes using logmgr?
5. Are you using any call-outs/call-ins? Any external
systems integration? Sometimes( for reasons beyond
my comprehension ) the objects allocated outside
Forte gets corrupted when its passed back and forth.
6. ...finally...Santa Clause, help me!
Ajith Kallambella M.
Forte Systems Consultant.
From: Eric Decossaux <[email protected]>
To: forte mailing <[email protected]>
Subject: (forte-users) access violation caught in debug mode
Date: Thu, 23 Sep 1999 17:31:39 +0200
Hello,
I have a problem using Forte in debug mode. If I run my program on my NT
machine from the partition workshop (distributed run), the program works
fine except that some object does not display what I'm expecting. So I
want to use the debug mode to inspect the objets of this window. When I
choose the "local variables" option to see the content of my window, I
have a "access violation caught" and forte disappears. If I just let my
program run without choosing this option, everything is the same than
with the distributed run.
Does somebody have an idea what to look for ? I really want to look the
inside the attributes of this window.
We recently upgraded from release 30G2 to release 30L2. Could it be the
problem ?
Eric Decossaux
Cliniques Universitaires St Luc
Informatique des Laboratoires
av Hippocrate 10 / 1730
1200 Bruxelles
+32+2+764 17 53
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Re: (forte-users) Unstable server ENV after upgrade to Forte30M2.

I see/suggest a few things:
1) In your #1, you mention ".... development and test environments which use the
same Forte 3M installs through links ...". This concerns me. On our UNIX box
each environment has it's own directory containing it's own install. If your
environments are some how sharing a node manager, log directory or processes (to
name a few things) that is a recipe for disaster. They may be competing for
resources and usually the first one started will win.
2) I haven't done a lot with compatibility levels, but if an application built
in dev is to run in test it may be important that node managers and services
(autocompile, codegen etc.) be at the same level (????).
3) Check the definition files, to make sure the two environments operate
independently. If they are both trying to write to the same log file the one
started up first will work while the second will not as the file will be "busy".
4) We usually use rpcreate (newer version) to create brand new repositories.
Than we export/import the source code that we need. Also it is important to
force compile ALL plans in a workspace at least once after doing the import.
This will ensure that all of the code is "speaking the same language". The other
compile, only compiles those pieces of code that changed from the last compile.
Hope this helps.
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
"Braja Chattaraj" <forte_brajachotmail.com> on 09/13/2000 03:43:57 PM
Please respond to chattaraj_braja_NONLILLYlilly.com
To: forte-userslists.xpedior.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) Unstable server ENV after upgrade to Forte 30M2.
We are running Forte 3M2 clients and server in our test environment with
clients on NT and server on Solaris 2.6. Eversince the upgrade from 3L to 3M
we have been having an unstable environment that does not remain alive for >
10 mins. These are the details of the Forte installs and server setups :
1. The server hosts the development and test environments which use the same
Forte 3M installs through links (same ftcmd, ftexec, nodemgr, etc.). The
environments are at compatibility levels 0 and 1 respectively.
2. The two environments have the same definition files (defining the ENV
variables), though seperate copies and the two environments are hosted on
different ports on the same server.
3. While building the new 3M environmnets in DEV and TST, we exported the
old 3L repositories and imported them into the new 3M repositories and
deployed the applications.
While the DEV environment is stable the TST environment is not. This has
been observed while moving plans between the environments (export and
import) using fscript commands, deploying the apps after the move using
fscript, and testing the apps. Sometimes it has come down right after a
startup. There is no programatic reference to the environment agent in the
code. So, a programatic shutdown is ruled out.
Does anybody have a clue or a similar experience ?
Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BRAJA KISHORE CHATTARAJ
Consultant, Analysts International.
Work : Sphinx Pharmaceuticals (A division of Eli Lilly & Co.)
(919) 314-4134
Home : 1801, Williamsburg Rd., #41H, Durham, NC 27707.
(919) 463-7802
E-mail : forte_brajachotmail.com
Visit us www.analysts.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://profiles.msn.com.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

We found a solution to our issue.Their desktops were in a lockdown environment and the essbase.id file located in the windows directory was locked as well. This file is responsible for assigning ports etc and it couldn't be updated for the 6.5.4p2 upgrade. Once the file was deleted and the user reconnected to Essbase, the essbase.id was reset and they could connect.

RE: (forte-users) Hi All....very urgent...Forte doesn'thandle La rge ar

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) Events in Interface

I know, I've implemented similar structures in other locations as well,
always without problems. I've even recreated the whole interface, building
it completely from dragging and dropping methods and events from the class
to the interface. Then I did a force compile of the whole workspace. It
still doesn't solve the problem. There must be some combination of things
that were different in the other circumstances, but I don't seem to be able
to find it. It's definately not an error in the code. There something wrong
in Forte internally, but I don't know which combination of factors causes
it.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Moris_Mihaildis/AUST/CSCcsc.com
[mailto:Moris_Mihaildis/AUST/CSCcsc.com]
Sent: Tuesday, April 03, 2001 5:00 AM
To: Rottier, Pascal
Cc: forte-userslists.xpedior.com
Subject: Re: (forte-users) Events in Interface
FYI. We are using Forte 3.0.J.4 and NT4.0 SP6, and have had no problems
implementing your pattern.
There should be no need for a fix (cast). There is something wrong with
your interface.
Regards,
Moris Mihailidis
Consulting
CSC
Level 4, 570 St. Kilda Road, Melbourne VIC 3004
Ph: 61-3-95364675 Fax: 61-3-95364633 Email: mmihailicsc.com.au
"Rottier, Pascal" <Rottier.Pascalpmintl.ch> on 04/02/2001 09:52:46 PM
To: "'Forte Users'" <forte-userslists.xpedior.com>
cc:
Subject: (forte-users) Events in Interface
We have the following scenario:
There is a Service Object that acts as a Facade (Facade pattern) for 3
manager classes that implement some business functions. Each of these three
managers are stored as private attributes on this Service Object.
For the sake of flexibility, these three private attributes are defined by
their Interface, not their class. When the Service Object opens an Event
Loop and registers for the events of one of these interfaces, the whole
partition crashes. Even when using the running man in the development
workshop, the whole partition crashes. The only way to fix that is to cast
the Interface to a class that implements the interface before registering
for the event.
I know it's possible to register for events using an Interface that
contains
these events, rather then a class that implements the events. Of course, at
runtime you do need a real instance of a class that implements the
interface, otherwise you get a NIL-exception.
Does anyone have any experience registering for events from Interfaces? Are
there unexpected circumstances where it should work semantically, but still
causes Forte to crash. We're using Forte 3.j.1 on NT 4.0 SP 6.
Any help is appreciated.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

I know, I've implemented similar structures in other locations as well,
always without problems. I've even recreated the whole interface, building
it completely from dragging and dropping methods and events from the class
to the interface. Then I did a force compile of the whole workspace. It
still doesn't solve the problem. There must be some combination of things
that were different in the other circumstances, but I don't seem to be able
to find it. It's definately not an error in the code. There something wrong
in Forte internally, but I don't know which combination of factors causes
it.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Moris_Mihaildis/AUST/CSCcsc.com
[mailto:Moris_Mihaildis/AUST/CSCcsc.com]
Sent: Tuesday, April 03, 2001 5:00 AM
To: Rottier, Pascal
Cc: forte-userslists.xpedior.com
Subject: Re: (forte-users) Events in Interface
FYI. We are using Forte 3.0.J.4 and NT4.0 SP6, and have had no problems
implementing your pattern.
There should be no need for a fix (cast). There is something wrong with
your interface.
Regards,
Moris Mihailidis
Consulting
CSC
Level 4, 570 St. Kilda Road, Melbourne VIC 3004
Ph: 61-3-95364675 Fax: 61-3-95364633 Email: mmihailicsc.com.au
"Rottier, Pascal" <Rottier.Pascalpmintl.ch> on 04/02/2001 09:52:46 PM
To: "'Forte Users'" <forte-userslists.xpedior.com>
cc:
Subject: (forte-users) Events in Interface
We have the following scenario:
There is a Service Object that acts as a Facade (Facade pattern) for 3
manager classes that implement some business functions. Each of these three
managers are stored as private attributes on this Service Object.
For the sake of flexibility, these three private attributes are defined by
their Interface, not their class. When the Service Object opens an Event
Loop and registers for the events of one of these interfaces, the whole
partition crashes. Even when using the running man in the development
workshop, the whole partition crashes. The only way to fix that is to cast
the Interface to a class that implements the interface before registering
for the event.
I know it's possible to register for events using an Interface that
contains
these events, rather then a class that implements the events. Of course, at
runtime you do need a real instance of a class that implements the
interface, otherwise you get a NIL-exception.
Does anyone have any experience registering for events from Interfaces? Are
there unexpected circumstances where it should work semantically, but still
causes Forte to crash. We're using Forte 3.j.1 on NT 4.0 SP 6.
Any help is appreciated.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) Forte External Connection - PhysicalPort

Hi Ronald,
I think that ExternalConnection class is only aplicable for communication
using TCP, DECnet or Unix Domain Sockets, and is not applicable to work with
COM ports.
I think that to use COM port you must employ C with the Forté WRAPPER.
Daniel
-----Mensaje original-----
De: Ronald Celis <[email protected]>
Para: Daniel <[email protected]>; Ming Yan, Lam <[email protected]>
CC: Jose Ignacio <[email protected]>; Manuel_Fernández <[email protected]>;
Federico_Muñoz <[email protected]>; Lista_Forté <[email protected]>
Fecha: lunes 20 de diciembre de 1999 16:33
Asunto: RE: (forte-users) Forte External Connection - Physical Port
Did you try to use the ExternalConnection Class??????????????
it's documented in the "Integrating with External Systems" Forte Manualpage 228 )
>
Hope this help
--- Daniel <[email protected]> wrote:
Hello Lam,
I had some experience about this problem and first answer is that you
MUST
use the wrapper. You must realize that if you could develope Forté based
RS-232 functions they would't be portable to any other machines that have
not the same architecture than the one you use to develope.That's not the
philosophy of portability of Forté.
I suggest to create a few single task C programs,
1) Open serial port.
2) Close serial port.
3) Write to serial port.
4) Read from serial port.
5) Check if there is something in serial port.
and "put them into a library" to make them usable by TOOL via a portable
Forté class.
Best regards,
Daniel.
Daniel GonzáLucas
EAM Sistemas Informáticos S.L.
tel. + 34 983 35 29 22
fax.+ 34 983 35 21 15
e-mail:[email protected]
-----Mensaje original-----
De: Ming Yan, Lam <[email protected]>
Para: Forte Users Group <[email protected]>
Fecha: jueves 16 de diciembre de 1999 8:55
Asunto: (forte-users) Forte External Connection - Physical Port
Hi,
If anyone out there have tried to use Forte to communicate (transmit
data) to an external connection, which is a physical port such as Com 1,
Com 2, Xyplex. I would like to know how does Forte handle this type of
connection or does it have to use C program for this?
Thanks in advance
Ming Yan
BASS Consulting Sdn. Bhd.
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a
new
email the word: 'Unsubscribe' to: [email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
=====
Ronald Celis
[email protected]
Forte Consultant
International Business Corporation
http://www.ibcweb.com
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Did you try to use the ExternalConnection Class??????????????
it's documented in the "Integrating with External Systems" Forte Manual ( page 228 )
Hope this help
--- Daniel <[email protected]> wrote:
Hello Lam,
I had some experience about this problem and first answer is that you MUST
use the wrapper. You must realize that if you could develope Forté based
RS-232 functions they would't be portable to any other machines that have
not the same architecture than the one you use to develope.That's not the
philosophy of portability of Forté.
I suggest to create a few single task C programs,
1) Open serial port.
2) Close serial port.
3) Write to serial port.
4) Read from serial port.
5) Check if there is something in serial port.
and "put them into a library" to make them usable by TOOL via a portable
Forté class.
Best regards,
Daniel.
Daniel González de Lucas
EAM Sistemas Informáticos S.L.
tel. + 34 983 35 29 22
fax.+ 34 983 35 21 15
e-mail:[email protected]
-----Mensaje original-----
De: Ming Yan, Lam <[email protected]>
Para: Forte Users Group <[email protected]>
Fecha: jueves 16 de diciembre de 1999 8:55
Asunto: (forte-users) Forte External Connection - Physical Port
Hi,
If anyone out there have tried to use Forte to communicate (transmit
data) to an external connection, which is a physical port such as Com 1,
Com 2, Xyplex. I would like to know how does Forte handle this type of
connection or does it have to use C program for this?
Thanks in advance
Ming Yan
BASS Consulting Sdn. Bhd.
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
=====
Ronald Celis
[email protected]
Forte Consultant
International Business Corporation
http://www.ibcweb.com
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: (forte-users) workspace-open [Virus checked by NAINetshield]

Similar Messages

Maybe you are looking for