RE: (forte-users) Accelerator keys under MS Windows95/98/NT

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEF001.9C8C0B50
Content-Type: text/plain
Unfortunately, ALT key is not recognized as a validkey modifier on Windows
That isn't entirely true. The ALT key is recognized. I've used it
successfully
under Windows 95 and NT. The only annoying side-effect is that you get the
standard operating system beep when you perform the keypress.
-----Original Message-----
From: "Ajith Kallambella" [SMTP:[email protected]]
Sent: Thursday, August 26, 1999 1:43 PM
To: "[email protected]" [SMTP:[email protected]];
"[email protected]" [SMTP:[email protected]]
Subject: Re: (forte-users) Accelerator keys under MS Windows 95/98/NT
The Window class has a method named SetAsFunctionKey
and an event named FunctionKeyPress. When used
in combination, the former can be used to configure
various accelerator keys for the window widgets
and the latter can be used to trap them.
For more details, take a look at Forte online help.
Unfortunately, ALT key is not recognized as a valid
key modifier on Windows, but is only available on
Unix and VMS - for reasons beyond my comprehension :(
Hope this helps
Ajith Kallambella M.
Forte Systems Consultant.
From: "Burns, Troy" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: (forte-users) Accelerator keys under MS Windows 95/98/NT
Date: Thu, 26 Aug 1999 13:56:07 -0400
Let's say I have a pushbutton on a window and I've given it
label text of "&Search". In past developer-lives, the ampersand
is what gives the button the ability to respond to ALT-S. This
doesn't appear to be the case in Forte. What do I need to do
to make this work?
Thanks in advance,
Troy Burns
E-mail: [email protected]
Marriott Vacation Club International
941-688-7700 ext. 4408
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]
------_=_NextPart_001_01BEF001.9C8C0B50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<DEFANGED-META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<DEFANGED-META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<DEFANGED-TITLE>RE: (forte-users) Accelerator keys under MS Windows =
95/98/NT</TITLE>
</HEAD>
<BODY>
> Unfortunately, ALT key is not recognized as a =
valid
 key modifier on Windows

That isn't entirely true. The ALT key is recognized. =
I've used it successfully
 under Windows 95 and NT. The only annoying =
side-effect is that you get the
 standard operating system beep when you perform the =
keypress.

-----Original Message-----
 From: "Ajith Kallambella" =
[SMTP:[email protected]] 
 Sent: Thursday, August 26, 1999 1:43 PM
 To: "[email protected]" =
[SMTP:[email protected]];
 "[email protected]" =
[SMTP:[email protected]]
 Subject: Re: (forte-users) Accelerator keys under MS =
Windows 95/98/NT

 
The Window class has a method named =
SetAsFunctionKey
 and an event named FunctionKeyPress. When =
used
 in combination, the former can be used to =
configure
 various accelerator keys for the window =
widgets
 and the latter can be used to trap them.

For more details, take a look at Forte online =
help.

Unfortunately, ALT key is not recognized as a =
valid
 key modifier on Windows, but is only available =
on
 Unix and VMS - for reasons beyond my comprehension =
:(

Hope this helps

Ajith Kallambella M.
 Forte Systems Consultant.

 
>From: "Burns, Troy" =
<[email protected]>
 >To: "'[email protected]'" =
<[email protected]>
 >Subject: (forte-users) Accelerator keys under MS =
Windows 95/98/NT
 >Date: Thu, 26 Aug 1999 13:56:07 -0400
 >
 >Let's say I have a pushbutton on a window and =
I've given it
 >label text of "&Search". In =
past developer-lives, the ampersand
 >is what gives the button the ability to respond =
to ALT-S. This
 >doesn't appear to be the case in Forte. =
What do I need to do
 >to make this work?
 >
 >Thanks in advance,
 >
 >---------------------------------------------
 >Troy Burns
 >E-mail: [email protected]
 >Marriott Vacation Club International
 >941-688-7700 ext. 4408
 >
 >--
 >For the archives, go to: <A =
HREF=3D"<a href=
"http://lists.sageit.com/forte-users">http://lists.sageit.com/forte-users</a>" =
TARGET=3D"_blank">http://lists.sageit.com/forte-users</A> and =
use
 >the login: forte and the password: archive. To =
unsubscribe, send in a new
 >email the word: 'Unsubscribe' to: =
[email protected]
 >

 
_______________________________________________________________=

 Get Free Email and Do More On The Web. Visit <A =
HREF=3D"<a href="http://www.msn.com">http://www.msn.com</a>" =
TARGET=3D"_blank">http://www.msn.com</A>

--
 For the archives, go to: <A =
HREF=3D"<a href=
"http://lists.sageit.com/forte-users">http://lists.sageit.com/forte-users</a>" =
TARGET=3D"_blank">http://lists.sageit.com/forte-users</A> and =
use
 the login: forte and the password: archive. To =
unsubscribe, send in a new
 email the word: 'Unsubscribe' to: =
[email protected]

</BODY>
</HTML>
------_=_NextPart_001_01BEF001.9C8C0B50--

Hi,Beau Leo, I am having problem installing Oracle9i Database Rel.2 on my pc.
I read the suggestion and solution you posted for fixing Oracle 8.1.x installation
probblem, and since my pc also hung at 48% while installing Oracle 9i software,
I wonder if the same problem in the Oracle8 Vs.Pentium4 also exists for Oracle9i.
I have Windows2000,256RAM, Pentium3 1Ghz, and 13.8 free diskspace. But the installation always
hangs at 48%, my computer will just shut down and restart automatically without
even showing an error message. I have tried installing the Enterprise edition for 3
times already but everytime encountered the same problem. I've also tried custom installation
by selecting not to create database, but it also hung.
Before I started each installation, I always made sure that my registry and environment
path are cleared and that all the partially-installed Oracle files are deleted.
I hope that you or anyone who has a solution for this problem could be so kindly to help me out.
Thank you in advance.
ailee

Similar Messages

Accelerator keys under MS Windows 95/98/NT

Let's say I have a pushbutton on a window and I've given it
label text of "&Search". In past developer-lives, the ampersand
is what gives the button the ability to respond to ALT-S. This
doesn't appear to be the case in Forte. What do I need to do
to make this work?
Thanks in advance,
Troy Burns
E-mail: [email protected]
Marriott Vacation Club International
941-688-7700 ext. 4408

I developed my application in LabVIEW 5.1.1 on Windows NT 4. I view the developed application from LabVIEW 6i on Windows 2000. Most of the problems that I have are related to data coersion from one VI to another. But those are just warnings and the program will run just fine.
I have also developed applications in LabVIEW 5.1.1 on Windows 98 and used it in LabVIEW 5.1.1 on Windows NT 4 and do not have any problems.
The drivers that I use are supported in Windows 2000. I have heard of people running into problems when porting application from Win98 to Win2000 but that's because the released drivers have not been throughly tested under Windows 2000. There are instructions in WinNT that does not apply in Win2000. That's when you typically run into problems.
Hope that
helps.
Shan Pin Koh
Systems Engineer
Oakriver Technology

RE: (forte-users) user name

Troy Burns wrote:
It would definitely be of interest to me, since this is an item on my
"to-do" list. If you can release the code, let me know.Here 'tiz.
The files you're getting are:
SFVosC.pex - "C" wrapper.
Vos.C - The "C" callout.
Vos.H - A header file for Vos.C, used by ...
VosCLI.C - A command-line-driven mainline to test Vos.C
VosObj.CEX - An object that provides a "nice" interface to the "C" wrapper.
We use this in two ways: instantiated as a local object to get the username
under VMS or NT, or as a service object partitioned to an NT server to do
username/password authentication on behalf of clients on other operating
systems.
The following changes have been made throughout the files in an attempt to
keep various people in DuPont happy:
"our_application_root" replaces the actual name of the root directory of
the application.
"our_vms_server" replaces the actual name of the system in question.
"our_nt_server" replaces the actual name of the system in question.
"our_application_name" replaces the actual name of the application.
A copyright notice, the usual disclaimer, and a "fair use" statement (which
is just a reference to the Perl Artistic License) have been inserted.
Except for the "ExternalObjectFiles" declaration in SFVosC.pex, all the
changes appear to have been in comments. But the files come with the usual
freeware warranty (i.e. "use at your own risk".)
Have fun with these!
Tom Wyant
(See attached file: SFvosC.pex)(See attached file: Vos.c)(See attached
file: Vos.h)(See attached file: Voscli.c)(See attached file: VosObj.cex)

I would try going to the "lowest common denominator" between WindowsNT and
Windows95 - DOS. Both windowing OS's sort of have their roots in DOS, or at
least both are capable of opening a DOS session.
Therefore, from a DOS prompt type "set" to view the environment variables for
both OS types. Look for a common variable between the two that stores the
userID. If you can find one of these your application will be that much more
portable between these two Windows mutations.
I used "set" on my NT and found my userID assigned to a few variables. I haven't
done this on a Windows95 machine in quite some time, but if the machine is on
the network it should have at least one environment variable with the userID.
I'm just guessing that DOS has a variable to store the userID that will be
common to both machines.
Good luck....
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!
"Olivier Andrieux" <oandrieuxaxialog.fr> on 07/19/2000 09:12:41 AM
To: forte-userslists.xpedior.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) user name
Hi
I use this command to catch the username:
task.part.operatingsystem.getenv('username')
with NT, there is no problem
but with windows95 or 98 the command doesn't find the username.
Thanks in advance.
Olivier Andrieux
Axialog
Lille
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) User-visible service object

This solution will cause network traffic for all method calls on the
environment visible SO. This overhead is not incurred when calling methods
on a user visible SO in the same partition. Depending on the frequency of
calls and the volume of data being passed in and out, this could be
significant overhead.
We have successfully implemented the following.
Create a second User Visible SO based on the same class. Then you will be
able to partition the one SO into the client partition and the second into
the server partition.
For example, assume the underlying class is named MessageService then define
your SO's as
ClientMessageService -> MessageService
ServerMessageService -> MessageService
Andy
-----Original Message-----
From: Amin, Kamran [mailto:kamran.aminlendware.com]
Sent: Wednesday, August 23, 2000 10:17 PM
To: 'Duncan Kinnear'; kamranaminyahoo.com
Subject: RE: (forte-users) User-visible service
object
Duncan,
Make the user visible service object to an
environment visible
service object. This way the client and any service object
on the server
can access it.
ka
-----Original Message-----
From: Duncan Kinnear [mailto:duncanmccarthy.co.nz]
Sent: Wednesday, August 23, 2000 7:47 PM
To: kamranaminyahoo.com
Subject: (forte-users) User-visible service object
Hi folks!
We've got a user-visible service object that handles
initialisation of and
access to the message catalog.
This works well on the client, but we would like to use the
same
mechanism (and even the same service object) on the server
so that
service objects on the server have access to their message
catalog on
the
server.
I was hoping that if we referenced this user-visible service
object in
both the client and the server code, that it would partition
a copy in
each of the client and server partitions. However, we
cannot get this
user-visible service object duplicated on the server. If we
drag and drop
it onto the server partition in the partition workshop, it
disappears from
the client partition!
Anybody got any idea how we could do this?
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
duncanMcCarthy.co.nz
PO Box 764, McLean Towers, Phone: +64
6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64
6 834 3369
Providing Integrated Software to the Meat Processing
Industry for over 10
years
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

I would try going to the "lowest common denominator" between WindowsNT and
Windows95 - DOS. Both windowing OS's sort of have their roots in DOS, or at
least both are capable of opening a DOS session.
Therefore, from a DOS prompt type "set" to view the environment variables for
both OS types. Look for a common variable between the two that stores the
userID. If you can find one of these your application will be that much more
portable between these two Windows mutations.
I used "set" on my NT and found my userID assigned to a few variables. I haven't
done this on a Windows95 machine in quite some time, but if the machine is on
the network it should have at least one environment variable with the userID.
I'm just guessing that DOS has a variable to store the userID that will be
common to both machines.
Good luck....
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!
"Olivier Andrieux" <oandrieuxaxialog.fr> on 07/19/2000 09:12:41 AM
To: forte-userslists.xpedior.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) user name
Hi
I use this command to catch the username:
task.part.operatingsystem.getenv('username')
with NT, there is no problem
but with windows95 or 98 the command doesn't find the username.
Thanks in advance.
Olivier Andrieux
Axialog
Lille
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

Accelerator Key

I would like to create a shortcut key, such as Ctrl+space or Ctrl+z, that users can press when they get to a field which has a drop down list to display the list without having to use their mouse and click on the down arrow. The lists are either displayed from a Choice List or run a sql query to a database.
I looked at using an Accelerator key but cannot get that to work.
Is what I want to do possible? Any ideas on how I can accomplish it?
Thanks in advance.
Mary

Yes we are using Form Designer 5.0. The objects I'm using are Drop Down List Boxes.
I didn't know about the DropOnEnter=True property (I'm kind of new at this) but that works well if I have a Choice List typed under List in the properties of the object, but if I run a query in code it doesn't work. If, in the properties, I change the DropOnEnter=True I need to also change the DropDownStyle to DropDownList (according to something I read). If I do that, it works perfect when I have a choice list but the drop down list won't even display with a mouse click for the db query. If I have the DropDownStyle set to DropDown Combo, the list will display from the query when I enter the field, but when I leave the field after pressing Enter to select one item, the data disappears.
I have tried playing with different settings under Properties as well as looking at the code under the onExit and DropDownClick events for the object but am not sure.
Here is the code under the two events which might give you some insight. I tried playing with the defaultselection and currentselection but as of yet haven't gotten it to work.
It would be great if it worked just like it does with the Choice List.
OnDropDownClick
Dim oRS
Dim strList
Dim szSQL
psrelcode.Clear()
If (psrelcode.ListCount = 0) then
if rbbus.Value = rbbus.OnValue then
szSQL = "Select reldesc,relcode from relate where relcode = 'ADV' OR relcode = 'AKA' OR relcode = 'SUB' OR relcode = 'PAR' OR relcode = 'FKA' order by reldesc"
Set oRS = WFDataClient.ConvertToRecordset(WFDataClient.ExecuteReturnDataSetWithConnName(szSQL,"conn _son2"))
else
rbindiv.Value = rbindiv.OnValue
szSQL = "Select reldesc,relcode from relate where relcode = 'ADV' OR relcode = 'OC' OR relcode = 'PTR' OR relcode = 'PADV' OR "_
& "relcode = 'SP' OR relcode = 'EXPW' OR relcode = 'FKA' OR relcode = 'HEIR' OR relcode = 'TRUST' OR relcode = 'COOWN' OR "_
& "relcode = 'DIR' OR relcode = 'PRINC' OR relcode = 'CODEF' OR relcode = 'COCSL' order by reldesc"
Set oRS = WFDataClient.ConvertToRecordset(WFDataClient.ExecuteReturnDataSetWithConnName(szSQL,"conn _son2"))
End if
Do Until oRS.EOF
strList = strList & Trim(oRS(0)) & ";" & Trim(oRS(1)) & vbNewline
oRS.MoveNext
Loop
psrelcode.ChoiceList = strList
psrelcode.DefaultSelection = 0
End if
OnExit
Dim oRS
Dim strList
Dim szSQL
psrelcode.Clear()
form.BusyCursor = True
If (psrelcode.Text <> "") Then
szSQL = "Select reldesc,relcode from relate where reldesc = '" & psrelcode.Text & "'"
Set oRS = WFDataClient.ConvertToRecordset(WFDataClient.ExecuteReturnDataSetWithConnName(szSQL,"conn _son2"))
If (oRS.recordCount > 0) then
if (oRS.RecordCount = 1) then
psrelcode.Text = Trim(oRS(0) & "")
ReCode.Text = Trim(oRS(1) & "")
psrelcode.DropDownStyle=1
else
psrelcode.Text=""
ReCode.Text = ""
end if
Else
psrelcode.Text = ""
ReCode.Text = ""
form.BusyCursor = False
msgbox "No records found matching your criteria. Please try again.",vbinformation,"Relationship Lookup"
form.GoToField(psrelcode)
End if
Else
psrelcode.Text=""
ReCode.Text = ""
End if
psrelcode.CurrentSelection = 0
form.BusyCursor = False
Thank you in advance.
Mary

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) Reporting tools/components for ForteApplications?

Hi Robert,
A good place to start when it comes to reporting is Forte Consulting. They
have developed a tool called ReportKit, which is ActiveX integration with
Seagate Software's Crystal Reports tool. Crystal is not really a three-tier
tool (although, your Forte Consultant can probably set it up to mimic a
three-tier tool), but it is a quick, easy way to get quality reports from
your existing Forte applications. If you're interested, give your Forte
Sales Rep (or, better still, your Forte Regional Consulting Director) a
call. They can discuss pricing and scheduling. I've done several
integration projects with Crystal, and I highly recommend ReportKit for
small- to medium-sized reporting requirements. As for costs, I don't recall
how much CrystalReports runs, but I think there are developer licenses and
runtime licenses.
FYI, the actual integration of ReportKit is pretty quick. The more
time-consuming piece of any report tool integration is the design and
implementation of the reports to be used.
I hope this helps.
-Katie
Katie Tierney
Quality Management Analyst
Akili Systems Group
601 Jefferson, Suite 3975
Houston, Texas 77002
Office: (713) 655-1400
Cell: (409) 255-1643
"The bitterness of poor quality remains long after the sweetness of low
price is forgotten" --Larry Anderson
-----Original Message-----
From: Robert Brooke-N502365 [mailto:Robert.Brookeca.michelin.com]
Sent: Monday, February 14, 2000 8:17 AM
To: kamranaminyahoo.com
Subject: (forte-users) Reporting tools/components for Forte
Applications?
Hi all,
We are looking for what is currently in the marketplace to enhance the
reporting
capabilities of Forte. Ideally, we are looking for component libraries that
we
could import into our repository. Do these exist?
Currently, I have found six reporting tools that are out there. The
tools
are Actuate, Crystal Reports, Report Workshop from Indus Consultancy
Services, Brio Technologies (SQR) VisualBRIO, Visual CyberQuery from
Cyberscience Corp., and Beacon from Brahma Software Solutions FORTify
Components. Are there any others for Forte?
If anyone is currently using one of these Reporting Tools for Forte or
any
others, could you give me any indications as to the costs, training, type
of
application using the Reporting tool, would you recommend using the
product
again, does it use wrappering or API, or is it a component based tool, and
any
other relevant information on the product?
Thanks,
Robert Brooke
Application Developer
Michelin North America (Canada) Inc. CA0/CA1
PO Box 399
New Glasgow, Nova Scotia
B2H-3E6
Phone: (902) 753-1977
Fax: (902) 396-2180
Note: We are currently developing in Forte 3.0.L.2. However, we would
like
to select a reporting tool/component within the next month. We are in the
initial phases of our next project, an application to be developed
in-house.
Probably will have two databases, one for real-time data and another one
for
archived data. Probably will need reporting functionality and capabilities
for
both real-time data and archived data.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
The E-Mail System is to be used for business purposes only.
www.mimesweeper.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

At 09:33 AM 4/20/01, Rottier, Pascal wrote:
Forte 4GL is:
1) A language, TOOL (Compare to Java)
2) An IDE (Compare to e.g. JBuilder or FJCE)
3) A collaborative development environment, with central repository (Compare
to ????)
4) A distributed application server / object request broker (Compare to J2EE
servers and/or CORBA)Let's not forget WebEnterprise, Express, and especially Fusion.
I think, SUN is not al all interested in TOOL.If TOOL were just a language and had no market yet, you are probably
right. But, not only is TOOL the key to the Forte environment, but it has
an existing and profitable market. Sun still sells FORTRAN, after all, and
continues to put money into ADE development for all its language
products. The real kicker, though, is that I think iPlanet is very clear
that Fusion, now iIS, is a very key product for them. There may be those
who wish it were written in Java and who might lobby for doing a Java
version, but it was clear at the conference that the iPlanet management
recognize that Java just isn't up to the task at this point. It isn't as
if all the iPlanet tools are actually written in Java, after all.
They will only support them for as long as they need.Or, more likely, for as long as they make money.
Now, in response to Microsofts .NET stratagy. We have yet to see how
succesfull this will be, but I expect Microsoft to push this down the
throats of developers and companies quite succesfully.Like they did DCOM?
=========================================================================
Thomas Mercer-Hursh, Ph.D email: [email protected]
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

Re: (forte-users) Minimal Fusion

Thomas,
A response which may contain no answers...and may lead to more questions...
As a novice fusion user, one of the largest obstacles to using Fusion is the lack of XML API's in an application, be it a customer's in-house or vendor's software product. Corresponding to this is simply the lack of any API's in the application. As Forte (abet Sun, now iPlanet) says in their training manual 'A nontrivial task is to build new adapters for your programs if you wish to enable them to interact using XML documents over HTTP'. This is probably an understatement.
The question that come to mind is:
Does the warehouse have published API's their product?
If not, then, IMHO, you have steep hill to climb, not the least being communication, cooperation, and coordination from the warehouse vendor (another one of those 'nontrivial tasks') in trying to create the required API's
if so, then it is a matter of building an adapter, in a language that is compatible with the warehouse's API (hopefully C or some derivation of) , that contains (1) a DOM (Document Object Module) to API Translator, (2) an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server (again, another one of those 'nontrivial tasks').
Forte (abet Sun, now iPlanet) suggests, and I would concur (with reservations), that if you haven't done this before you should probably hire their services from the Forte Integration Services group. Their costs (admittible high) should be offset be the time it would take to develop one on your own. A side benefit is working with them, you learn the process for making other adapters in the future. If Fusion is a marketing success, then the benefits should out weigh the costs.
The Forte Integration Services group markets, or will market, a Fusion Adapter Designer, some sort of a SDK, which assists in the creation of Adapters. I do not know the availability of that product at this time.
As to your question "Is it reasonable to consider doing this project under Fusion as a
getting-feet-wet experience?" If you (or your customer) can afford the costs, and the warehouse has published API's, I would say that you gotta get-your-feet-wet somehow. If the warehouse doesn't have published API's and are not willing to put forth the effort and resources to do so, I would say your chances of success are considerably less.
In any case, IMHO, it will be a 'non trivial' undertaking.
-later
-labeaux
"Thomas Mercer-Hursh, Ph.D." <thomascintegrity.com> 10/31/00 04:49PM >>>This may be one of those questions which has no answer, but ...
Our long term plan is to develop XML APIs to each of the modules in our
suite of non-Forte applications and to integrate these under Fusion, thus
gaining Conductor management of the inter-module work flows and a cleaner
loose coupling of the applications along with other benefits such as the
ease of integration with other packages, a clean way to migrate to Forte
modules, and an ease of interconnecting "mini-applications" to address
specific customer needs.
I have an existing customer who has made a decision to migrate to a third
party warehouse from an in-house warehouse. I.e., were this transition to
the new structure complete, this would correspond to unhooking some of our
modules and replacing these with an adapter to the corresponding modules in
the third party warehouse.
In fact, as it looks now, I will need to build the logical equivalent of
these APIs anyway -- might as well do it in XML, right? And these APIs
will communicate with a daemon responsible for the message traffic to and
from. I tried to get this traffic to be XML and to use MQSeries or JMS as
the transport, but the folks at the warehouse end don't seem to be able to
handle such things, so I am stuck doing something fairly stupid for the
actual communication.
So, the question for those out there who have already paid their Fusion
dues, is it reasonable to consider doing this project under Fusion as a
getting-feet-wet experience. There are only half a dozen APIs to do and I
have to do those anyway and am inclined to make them XML regardless. There
will be one communication daemon to which all these connect and the
business processes originally implemented in Conductor will basically be
just point to point connects, except for routing traffic from the daemon to
the right API based on message type. That's really all I need it to do,
i.e., far too simple to actually need Fusion, but a possible opportunity
to get started and then to expand to other uses.
Crazy?
=========================================================================
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

At 07:55 AM 11/1/00, Labeaux Schiek wrote:
As a novice fusion user, one of the largest obstacles to using Fusion is
the lack of XML API's in an application, be it a customer's in-house or
vendor's software product.In this case, the good news is that one of the applications in question is
our own, so whipping up an XML API to suit each required transaction on
that side is no more, probably less, work than importing or exporting a
flat file or whatever. Moreover, my current expectation of how this
interaction will work is something like this:
</pre>
---Fusion------
| |
WACS<-->WACS_Daemon<----VPN socket
connection---->IS_Daemon I/S
</pre>
I.e., I/S, our application, and the IS_Daemon which handles the connection
traffic across the internet link are both mine. For I/S, I will create XML
APIs to suit. For the IS_daemon, I might use the transform facilities to
convert this XML to the pipe-delimited format they are expected at the
other end and make the daemon a simple manager of the connection or, the
daemon could do the conversion, but the former seems like the more
appropriate approach. The API between the two daemons is something we are
defining now (unfortunately I lost the argument to make that XML).
Corresponding to this is simply the lack of any API's in the
application. As Forte (abet Sun, now iPlanet) says in their training
manual 'A nontrivial task is to build new adapters for your programs if
you wish to enable them to interact using XML documents over HTTP'.My neophyte understanding is that, since I am defining the API to I/S in
the diagram above and I can make this XML, then the adapter issue
disappears there. I might have to create an adapter for the daemon, but if
necessary, I could make that the same XML on a pass through and do the
translation in the daemon.
If not, then, IMHO, you have steep hill to climb, not the least being
communication, cooperation, and coordination from the warehouse vendor
(another one of those 'nontrivial tasks') in trying to create the required
API'sWe are well through this process anyway. ... which is not to say that it
has been or will be easy, but it must be done whether I use Fusion or
not. Given that the vote has gone in favor of simple messages of
pipe-delimited records, i.e., basically flat file, the technical issues
there are minimal.
if so, then it is a matter of building an adapter, in a language that is
compatible with the warehouse's API (hopefully C or some derivation of) ,
that contains (1) a DOM (Document Object Module) to API Translator, (2)
an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server
(again, another one of those 'nontrivial tasks').I'm not sure I quite understand what you are saying here. The HTTP part
won't be there since we will apparently be connecting via a VPN sockets
connection. But, how are you distinguishing DOM and XML since DOM is a
particular form of XML? The XML API I build for I/S will be DOM compliant.
Forte (abet Sun, now iPlanet) suggests, and I would concur (with
reservations), that if you haven't done this before you should probably
hire their services from the Forte Integration Services group. Their
costs (admittible high) should be offset be the time it would take to
develop one on your own. A side benefit is working with them, you learn
the process for making other adapters in the future. If Fusion is a
marketing success, then the benefits should out weigh the costs.I am familiar with the "party" line. If I were building a complete
interface to another major product (I/S is roughly equivalent to JDEC in
coverage) in the context of an EAI project, I would happily invite them in
and hope to pick up pointers. Here, though, there are only 8 or 9 total
transaction types and either all of the interfaces are XML, i.e., no
adapter required as I understand it, or only the daemon will need an
adapter and that will be a choice I can make depending on how things
go. One does wish it were possible to sample a small piece of that
knowledge store without having to buy the whole thing, though.
The Forte Integration Services group markets, or will market, a Fusion
Adapter Designer, some sort of a SDK, which assists in the creation of
Adapters. I do not know the availability of that product at this time.Last I checked, one couldn't get this without the consulting ... hence the
last sentence above.
Thanks for your input.
=========================================================================
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

RE: (forte-users) Named Anchored Obj-EnvironmentFailover

I did some playing around with this stuff as well. I can tell you a few
things.
1) The search path option of connected environments only works for SO's, not
for named anchors.
2) When EnvA creates a directory "/glob", which contains object "obj1", then
EnvA owns directory "/glob". Even after restarting environments. If EnvB
tries to add a subdirectory to "/glob" or inserts its own objects into this
path, then the situation becomes unstable. It doesn't immediately produce an
error, but things go wrong anyway. Is this a bug or expected behaviour? I
don't know. I just learned not to do this. Every environment must place it's
named anchors in it's own tree. Directories can't be shared.
3) I think the relative name "glob/obj1" should work, but only if you set
the ObjectLocationMgr to start looking at the root. Default, it will start
looking in it's own environment basepath. But I don't have any experience
with this.
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: Master Programmer [mailto:masterprghotmail.com]
Sent: Monday, January 08, 2001 11:13 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) Named Anchored Obj-Environment Failover
Hi to all,
We connect from EnvA to EnvB giving the user directory parameter as / and
set the Environment Search Path
as EnvA:EnvB. From both environments we start and register
'/glob/obj1' named anchored objects with the same name.
From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
EnvB. And then we restart EnvA partition. We restart/rebind the client and
try to use object. We see that it is using the EnvB object.
Although we started the primary environment object again.
It is not using the search path. Once we shutdown secondary environment
it starts using primary environment object.
When we try to use relative path when we are binding the object
First parameter ('glob/obj1') No first slash. Trying 3rd parameter
for bind function or just using environment search path, Is is not able to
find the object. From nsls command I figured out that
under the root directory
/forte/UUID of ENVA/node
/site
/UUID of ENVB
/glob/obj1
names are available. When we use relative path (without slash)
is it trying to find /glob/obj1 under the /forte/UUID of ENVA
but we are registering the name under the root.
What is the reason of this odd behaviour or is this a bug?
Any answer will be appreciated,
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 did some playing around with this stuff as well. I can tell you a few
things.
1) The search path option of connected environments only works for SO's, not
for named anchors.
2) When EnvA creates a directory "/glob", which contains object "obj1", then
EnvA owns directory "/glob". Even after restarting environments. If EnvB
tries to add a subdirectory to "/glob" or inserts its own objects into this
path, then the situation becomes unstable. It doesn't immediately produce an
error, but things go wrong anyway. Is this a bug or expected behaviour? I
don't know. I just learned not to do this. Every environment must place it's
named anchors in it's own tree. Directories can't be shared.
3) I think the relative name "glob/obj1" should work, but only if you set
the ObjectLocationMgr to start looking at the root. Default, it will start
looking in it's own environment basepath. But I don't have any experience
with this.
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: Master Programmer [mailto:masterprghotmail.com]
Sent: Monday, January 08, 2001 11:13 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) Named Anchored Obj-Environment Failover
Hi to all,
We connect from EnvA to EnvB giving the user directory parameter as / and
set the Environment Search Path
as EnvA:EnvB. From both environments we start and register
'/glob/obj1' named anchored objects with the same name.
From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
EnvB. And then we restart EnvA partition. We restart/rebind the client and
try to use object. We see that it is using the EnvB object.
Although we started the primary environment object again.
It is not using the search path. Once we shutdown secondary environment
it starts using primary environment object.
When we try to use relative path when we are binding the object
First parameter ('glob/obj1') No first slash. Trying 3rd parameter
for bind function or just using environment search path, Is is not able to
find the object. From nsls command I figured out that
under the root directory
/forte/UUID of ENVA/node
/site
/UUID of ENVB
/glob/obj1
names are available. When we use relative path (without slash)
is it trying to find /glob/obj1 under the /forte/UUID of ENVA
but we are registering the name under the root.
What is the reason of this odd behaviour or is this a bug?
Any answer will be appreciated,
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 ADE

In addition to this confusion, I'd like to see some statement by Forte to
indicate
WHEN the next Forte R4 is scheduled (before the Sun era is was said to be
Summer 2000) and
WHAT exactly it will contain (major headings will do).
With the cancellation of the Forte Forum event doubt and uncertainty are
spreading in the
Forte communities that I talk with and no one seems to counterbalance these
doubts with an
official statement. How serious does Sun take TOOL Forte for the coming few
years? Release
of Fusion V2 seems to say "serious". The deafning silence with regard to R4
indicates the
opposite. And the users are divided (as always).
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
-----Original Message-----
From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
Sent: Tuesday, 18 April, 2000 17:49
To: 'kamranaminyahoo.com'
Subject: (forte-users) Forte ADE
A long, long time ago
In a galaxy far away....
I saw a demonstration of Forte's new Application Development
Environment,
which was more userfriendly than the current one. It also looked more
similar to the interface of the other development tools out
there, with a
tree structure and capabilities to browse through the
inheritance tree, and
not opening a new window for every project, class and method that is
accessed.
This new interface was supposed to be included in Forte 4, which would
combine TOOL and Java and would be released soon.
Since then, we've seen SynerJ and now FJEE, but Forte 4 is still not
released. And when it will be released, it still won't
support TOOL and Java
simultaneously. That's OK. I understand that.
But now I've heard that this improved ADE won't even be
included in Forte 4.
Is this true? And if so, why?
Pascal
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

You may be interested in the following which comes from a statement of direction
recently issued by Sun.
Product Context
+ Forté 4GL is an award-winning, proven product with many unique advantages for
building
enterprise business systems that are distributed, that involve the integration
of existing
business systems as well as new functionality, and that target heterogeneous
runtime
environments.
+ Forté 4GL is recognized by Gartner Group as the most successful Enterprise
Application
Development Tool.
+ Forte 4GL has a substantial customer base that has been successful with the
product and that
looks forward to using Forté 4GL for new applications.
+ The Sun Microsystems, Inc. (SMI) development tools group (formerly Forté
Software, Inc.)
has a strong internal commitment to Forté 4GL. Forté Fusion is written with, and
is currently
being enhanced with Forté 4GL.
+ SMI has retained the Forté field sales organization as an independent unit
whose primary
product offerings are Forté 4GL and Forté Fusion. Continued volume sales of
Forté 4GL
remain the foundation of our business plan.
Product Future
+ We intend to actively enhance and promote Forté 4GL for the indefinite
future.
+ We believe Forté 4GL will flourish in the long term, especially if we are
able to harness the
considerable selling power of the entire SMI field sales organization. To make
the product
more attractive and easier to sell, we will continue to make the product more
modular and
easier to integrate with heterogeneous software environments.
+ We believe that the best opportunity for attracting new customers is to
leverage the ability of
Forté 4GL to easily build powerful shared business services (server components)
that can be
accessed by non-Forté clients (e.g., browsers, Java clients) and that can easily
integrate with
new and existing business systems.
+ We believe that Forté 4GL?s continued success is enhanced by continuing to
issue small and
frequent product releases. Our target is two such releases per year.
+ There is a great potential for our three product lines (Forté 4GL, Forté
Fusion, and Forté for
Java) to complement and reinforce each other. Interoperability among the three
product lines
is seen as a critical success factor for Forté 4GL.
Forte 4GL Statement of Direction Page 2
Sun Microsystems, Inc Proprietary and Confidential
Product Priorities
1. Interoperability with third party software components
+ External (non-4GL) client support (e.g., browsers, Java clients)
+ External server integration (e.g., messaging, component support, data
exchange)
2. Enhanced productivity
+ Increased automation (i.e., less coding)
+ Support for platform updates (e.g., new versions of OS, DBMS)
3. TOOL code to Java code migration
4. Unified developer look and feel with other Forte development products
5. Common repository
Short Term Product Plans
Mid-year release
+ New features available as ?preview? per the standard Forte maintenance
release procedures
+ Tentatively labeled ?release 3.5? and distributed as a free product
enhancement for
customers under maintenance
+ Scheduled for Summer 2000
+ Defining features
+ Introspection (reflection) ? the ability for an object to describe itself at
runtime
+ Improved integration with applications developed using Forté-for-Java
Community
Edition
+ Platform support improvements to track important operating system and
database
vendor activity
+ Target features
+ Display system enhancements (e.g., Motif 2 support, line arrowheads, window
refresh control, editable outline fields)
+ Dynamic library loading
+ Improved CORBA/IIOP support
+ Improved XML and XSLT class support
+ JMQ support
New year release
+ New features available as ?preview? per the standard Forte maintenance
release procedures
+ Tentatively labeled ?release 3.6? and distributed as a free product
enhancement for
customers under maintenance
+ Scheduled for year end 2000
+ Defining features
+ Any Release 3.5 target features that were not included in 3.5
+ Generation of EJB interfaces for R3 service objects
+ Platform support improvements to track important operating system and
database
vendor activity
+ Target features
+ COBOL record handling as part of the OS390 transaction adaptor
+ Improved runtime security
+ Interface classes for access to Netscape Server 4.0 and possibly other web
servers
Long Term Product Plans
+ To be determined by customer and market feedback.
+ A major criterion for new functionality will be enhancing the revenue
generating ability of
the product, thereby fostering its long-term health in the marketplace.
+ Substantial emphasis will be placed on creating new capabilities that enhance
the
attractiveness of the product for new users.
+ The contents of Release 3.7 (or whatever it will be called) will be
solidified just after release
3.5 ships. Subsequent planning visibility will be two forward releases.
"Klerk, Theo de" <Theo.de.Klerkcompaq.com> on 04/18/2000 12:27:36 PM
To: "'Rottier, Pascal'" <Rottier.Pascalpmintl.ch>,
"'kamranaminyahoo.com'" <kamranaminyahoo.com>
cc: (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: RE: (forte-users) Forte ADE

JTabbedPane w/ Accelerator Keys

I need to add accelerator keys to the tabs of a JTabbedPane, much like the accelerators in a JMenuItem (i.e. under-score for Alt-F, or CTRL-X, etc...).
Any suggestions?
Thanks!

It doesn't support accelerator, but it does support mnemonics. Check out the API for more information.

Launch programs with User defined Keys?

Im using 10.6.4 on a Macbook Pro and on the 1 screen im using 3 different programs at once (2 music programs and Parallels / Windows Program)
Is there a quick way to flip between the 3 very quickly as I like to view all 3 very quickly and chop and change between them on the Macbook Pro screen
I use Apple + Tab but this gets tedious trying to flip around between them going left and right
Does 10.6.4 allow you to user define keys to certain programs so you can launch and they become active?
ie: F1 - launch program 1, F2 - Launch Program 2 etc
So 1 button push makes a certain program active?
I was used to Windows, whereby everything stayed in a dock at the bottom and you could just launch any program at any time
I love Mac OS X but the only way I can find is either the Apple+Tab which gets tedious, or a Hot corner which i have set up and "spreads out" the programs : then again with hot corners your still having to chase around all your open windows!
Is there a quick easy solution for having up to 3 programs at once and instant access that I don't know about? With audio editing, i chop and change edits to see how they fit between programs so this would be invaluable
I'm pretty sure OSX would have something under the bonnet to do this?
Thanks

pitchfork wrote:
I was used to Windows, whereby everything stayed in a dock at the bottom and you could just launch any program at any time
Hi,
Um, so far as I'm aware this is the same behaviour in OS X. Launched programs that are not added to the Dock are appended to the right of the Dock, but applications in the dock do not move randomly - unless you count the fact that the Dock expands to include newly-added or -launched applications. To achieve what I think you're referring to, simply add the applications you use frequently to the Dock permanently, and use the same behaviour you were accustomed to in Windows to switch applications.
However, if you want to create a simple keystroke to switch to another application (whether open already or not), then try creating a new Automator Service to activate a given application, and assigning a keystroke to it. I've never actually created a working Automator action before, but I believe the following should work:
1) Launch Automator
2) Select "Library" in the left-hand column, and type "Applescript" in the search box.
3) There will be only one result, "Run Applescript." Drag this into the right-hand column.
4) Copy and paste the following script to replace the words "(* Your script goes here *)":
tell application "Amadeus Pro"
activate # switch to your application, launch if necessary
end tell
5) Replace "Amadeus Pro" with the name of the application you want to switch to. KEEP the inverted commas.
6) Make sure the drop-down menu in the top-right is set to "any application."
7) Choose "Save" from the File menu, and assign an appropriate name; this is how your Service will appear in the Services menu. You can now close Automator.
8) Finally, assign a shortcut in System Preferences » Keyboard » Keyboard Shortcuts » Services.
Give that a shot and see whether you're happy with it. Rinse and repeat with the names of the other applications if satisfied
Hope that helps,
S.

Re: (forte-users) How do you change the font color onwindow.StatusText

Hi Richard,
In the init method insert the line
<_StatusLine>.PenColor = C_BLUE ;
This sets the pen color for the widget.
StatusText is an attribute on the Window class that
holds the value of the text. This value is then
displayed in the specified data field that you assign.
Hope this helps,
Jairaj Rampershad
System Consultant
--- "Robinson, Richard"
<[email protected]> wrote:
I'm using Forte 3.0.G.2 and can't get the font color
to change.
I've followed the instructions in the help
documentation by creating a data
field widget (named it _StatusLine) and mapped it as
a TextData. In my Init
method I then have a chunk of code to set up the
Window.StatusText. It
looks like this:
_StatusLine = new;
Window.StatusText = _StatusLine;
Once that's done the code updates Window.StatusText
as needed. All this
works fine except I can't get the font color
changed. I've used the Window
workshop to specify a color for the data field
widget but it appears that
the underlying Forte libraries has a mind of it's
own. Any clues as what to
do? All I'm trying to do is set the color to the
default "information"
color - which is blue.
Thanks in advance
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]

It's not so simple to find it if you don't know what you're looking for... But it can be found via View - Show/Hide - Toolbar Items - Properties Bar.

RE: forte-users-digest V1 #1490

Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Re: (forte-users) Oggetto: Re: (forte-users) mouseCursors

Luca,
Forte makes use of mouse settings on the machine on which
the app is being run.
You can ad custom cursors by making the default
cursor schemes use your bitmaps( Windows/Control Panel/ Mouse ).
But when you deploy your app, if the client machine(s)
has a different setting, you will not see your
custom cursors.
I don't know if there is a way in Forte to tweak
Mouse settings on client machines. Even if there was a
way, how would you add the the custom cursor(s) to
app distribution??
Ajith Kallambella M.
Forte Consultant.
From: Luca Gioppo <[email protected]>
To: [email protected]
CC: [email protected]
Subject: (forte-users) Oggetto: Re: (forte-users) mouse Cursors
Date: Tue, 19 Oct 1999 17:20:00 +0200
Aready tryed, but with 'sad' result.
My application run under win '95 and cursors look really .. lets say
umpleasant.
I'd like to have a bitmap of mine or something like that.
Hoped that things like that were not so difficult, even with some
costraint.
Luca
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]

I went through the same process some time back. I
submitted a call to Forte and was informed that there
are hooks but they were intentionally undocumented
because Forte had plans to provide a interface to
Source Control Managers in future releases. If you
submit a call, they will send you a ZIP file
containing instructions on how to use the hooks. The
hooks have proven very useful.
--- Luca Gioppo <Luca.Gioppocsi.it> wrote:
>
>
I think that the topic is still open and alive.
In my case I have the need to integrate with PVCS
dimension.
The problem for me is that we develop both with java
and tool, and is
frustrating seeing java people smiling as tha
various tools give the chance to
integrate to various extends with source control
products.
I'm interested too in the problem, looking for a
solution since a bit, but no
satifactory solutions.
So count 2 on the problem.
Luca
"David Potts" <david.pottss1.com> il 23/11/2000
17.12.47
Per: forte-userslists.xpedior.com
cc: (ccr: Luca Gioppo/CSI/IT)
Oggetto: (forte-users) Source Control
Hello,
I'm looking how to do version control for forte
development, and have
done a search on the list archive. There are lots
of messages asking
how to do source control, but the answers all seem
to be "roll your
own". My questions are:
(1) Most of the postings seem to come from some
years ago. What is the
current state of play with source control for forte
4GL?
(2) There was some mention of "hooks". What are
these hooks?
(3) With Sun appearing on the scene, anyone got any
idea where source
control is going in future versions?
I'm very new to Forte, so sorry if this topic has
been closed.
Cheers,
Dave.
ATTACHMENT part 2 application/octet-streamname=david.potts.vcf
http://shopping.yahoo.com/

RE: (forte-users) Accelerator keys under MS Windows95/98/NT

Similar Messages

Maybe you are looking for