PanedWindow in Forte'
Hi,
I would like to build a desktop similar to the Partition Workshop one,
that is based on a form with due (or more) resizeable areas.
One other example are the Netscape Frames.
I know that this kind of window is called PanedWindow in the Motif
toolkit.
Do you have any suggestions to do this in Forte'?
Thank you in advance
Fabrizio
Barbero Fabrizio
CSI-PIEMONTE
Cso Unione Sovietica 216
10134 Torino ITALY
tel: +39 11 4618515
fax: +39 11 4618212
e-mail: [email protected]
I am assuming you mean ODBC instead of JDBC. If so then look at page 35 in http://docs.iplanet.com/docs/manuals/forte/forte4gl/35/adb.pdf.
ka
Similar Messages
-
Forgive me if I'm not replying to this correctly. I just got subscribed
and I can't believe this question popped up. I'm involved in the building
of a new imaging system using the Forte development environment. We are
currently in the prototyping stage and wanted to do just what you are
describing, "the browser" type window. Frames are pretty easy to do in
Forte. This may not be the best way, but it works.
We created a window which has 3 widgets panel one, panel two, and a
rectangle. The panels were to be parents of any "real windows" that you
wanted in you panes, like an outliner. The rectangle can be selected and
moved. We size all three explicitly. The main window has a startup
method and we send it parameters for positioning and determining if this
particular frame setup will be a horizontal type or a vertical type. The
frame control window has a resize children method which just re-sizes the
two panels based upon the position of the slider (rectangle). The neat
thing is that you can map one or both of your panels to another frame
control iff you set your startup parameters correctly. It seems pretty
crude but it takes very little code and you can nest the frame controls to
produce as many window panes as you desire. Getting around Forte's
geometry management was the toughest part, we wanted to take advantage of
the gridfields and automatic movement of widgets. However, we couldn't get
it to work. Might just be us, we are very new to the tool.
Al Menke
MSF&W
Springfield, IL
From: f.barbero <[email protected]>
To: [email protected]
Subject: PanedWindow in Forte'
Date: Wednesday, July 03, 1996 10:28 AM
Hi,
I would like to build a desktop similar to the Partition Workshop one,
that is based on a form with due (or more) resizeable areas.
One other example are the Netscape Frames.
I know that this kind of window is called PanedWindow in the Motif
toolkit.
Do you have any suggestions to do this in Forte'?
Thank you in advance
Fabrizio
Barbero Fabrizio
CSI-PIEMONTE
Cso Unione Sovietica 216
10134 Torino ITALY
tel: +39 11 4618515
fax: +39 11 4618212
e-mail: [email protected]In the 2E release there is a Sleep method on OperatingSystem, it
should be documented in the 2.0 addendum doc. This will put
the entire process to sleep for a specified number of milliseconds.
-jak
Jak Mang
Forte Software -
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.comHi 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 -
Using Forte 3.0 to deploy web app to iPlanet Web Server
Is anyone familiar with using Forte 3.0 to develop/deploy a web application to an iPlanet Server?
All I need is a simple walkthrough to create/deploy a "Hello World" app (it could be just a JSP) or a link to some document that covers this topic.
ThanksFor anyone who cares
First make a web module, then make a web application and add the web module you made. When adding it the Mapping field should contain whatever context of the module is. Then deploy the application. -
Hi All. I live outside of the USA and have an iPhone 4s. I'm going to Fort Lauderdale, FLA and want to data service for my iPhone ( navigation using google or imaps, browsing and voip ing when no wi fi available). I browsed the net but seems almost impossible. When I visited Toronto I was able to get data thru Koodo but I don't think this is offered in the USA. Anyone who has real experience with this please help. This is a situation that is best aided by persons who have experienced it. Thanks
Have a look here:
http://forums.macrumors.com/archive/index.php/t-982315.html -
Forte Transaction Management & 2PC
Forte Transaction Management & 2PC
The main purpose of 2PC in a distributed transaction manager is
to enable recovery from a failure that occurs during the window
of transaction commit processing. The Forte transaction manager was built
with this in mind but only with respect to the "volatile" (or "in memory")
objects that Forte manages. What this implies is that because Forte stores
objects in memory and not persistently on disk, the requirement of recovery
for these objects is significantly reduced (if not eliminated all together).
Forte follows a distributed 2PC model in that tasks and messages carry
along with them transaction identification and, during commit processing,
every distributed participant is polled for its availability to commit
the transaction. Applications saving persistent data to disk during a
distributed Forte transaction need to concern themselves with the potential
for failure during the commit processing window. Forte's prepare phase polls
each site (confirming a communications link with each distributed participant)
but no prepare request goes to the database primarily because (in release 1 and
2 of forte) no database supported a general distributed two-phase commit
(one could take issue with that in the case of Sybase, but rather than debate
this point, suffice it to say that the general direction in the industry for
support of this functionality was through TP monitors -- more on that later).
Once all sites are ready to commit Forte expects that the commit will
complete successfully. If at this moment, for example, a participating
Sybase server terminates (with data not yet committed) while a participating
Oracle server has already committed its unit of work, then the outcome of
the distributed transaction is inconsistent - if no one has yet committed
Forte will still abort the transaction. This "window of inconsistency"
is documented in the Forte TOOL manual.
Mission critical applications that require distributed transactions can
address this window of inconsistency in a number of ways:
* Utilize a TP monitor such as Encina (see below)
* Log distributed updates in an auxiliary database table (much like a
distributed transaction monitor's transaction-state log). This approach has
been the traditional banking application solution prior to the commercial
availability of products like Encina, Tuxedo, TopEnd, etc.
This solution is somewhat complex and is usually not generic enough
so as not to have to change code every time a new table or database
site is introduced into the application's data model.
* Rearrange the data model in order to eliminate the need for distributed
transactions. This is usually only a temporary solution (with smaller
numbers of active clients) and cannot be applied to complex legacy systems.
With the advent of the X/Open distributed transaction architecture (the
XA Interface) more database vendors have found that by complying with the
XA interface they can plug their database-specific implementation of
transaction into a globally managed transaction, with commit and abort
processing being conducted by a central coordinator. Of course, the
overall transaction manager coordinating the global transaction must
itself, persistently record the state of the different distributed
branches participating in the transaction. A significant portion of
the functionality provided by products such as Encina, Tuxedo, TopEnd and
OpenTP1 is to provide exactly this global transaction management.
Rather than extend the Forte distributed transaction manager with the
functionality necessary to manage and recover distributed transactions
that modify data on disk, Forte has chosen to integrate with the emerging
set of commercial transaction monitors and managers. This decision was
built into the original design of the Forte transaction model (using XA and
early Tuxedo white-papers as guidelines):
* In Forte release 2 an integration with Encina was delivered.
* In January 1997 a press release announced an integration of
OpenTP1 with Forte for release 3.
* The Forte engineering staff is currently investing integration
with other transaction management products as well.
Neil Goodman,
Forte Development.You don't. ("manage" a transaction)
There is nothing really to "manage".
A transaction is automatically started when you make any changes to data (e.g. fire off a DML statement).
You simply needs to issue a COMMIT or ROLLBACK when needed. A COMMIT at the end of the business transaction and not before (i.e. no committing every n number of rows). A ROLLBACK when hitting an exception or business logic error that requires the uncommitted changes to be undone.
That in a nutshell is it. It is that simple.
Oracle also supports creating savepoints and rolling back only some changes made thus far in the transaction.
The only other thing to keep in mind that a DDL in Oracle issues an implicit commit. Firing off a DDL with cause any exiting uncommitted transaction to be committed.
Transaction "logic/management" should not be made more complex than this. -
Automated Testing of Forte Applications
Dear Jim,
This is a technical and education Forum and I want to make sure everyone is
"educated" to your options out there. Our company specific purposes is
delivering testing solutions for Forte Developed applications. (Primary
responsibility is to help developers and qa staff) I have tried to answer
you questions as follows and to educate fellow Forte people on solutions
available to them. If you need more discussion about our tools, please
contact me directly.
To anyone interested in testing Forte Applications:
1) What product are developers using to automate the process of testing
Forte applications?
IQTest- Unit Level Testing Tool that tests specific Forte methods and
saves them for automatic regression testing.
IQTrace: Unit Level Pathway Testing. Tests specific method level and
functional threads and saves them for automatic regression testing.
2) If there is a tool, how long does it take to create a typical test?
- Class I.Q. automatically generate the test classes and instantiates the
object under test. A typical setup for a developer is about 30 minutes
which is done once. The actual process of testing methods or traces takes
seconds. All tests are saved to any Forte database for automatic
regression testings.
3) Can the test include the testing of persistance to a database?
Yes, Our products are written to test persistance in a database and all
fully supported to test service objects which is currently a major issue
that most development teams are running into problems with.
4) What type of testing can be performed: black box testing, white box
testing, integration testing, UI testing, etc.?
Class I.Q. is considered a "White Box" approach to testing. It is
exercising the source code and creating an output for each method call.
The test cases then are dynamically linked into a trace.
Some of the features of Class I.Q. Products:
- Automatic Test Class Generation
- Saving of Test Cases and Test Traces
- Groups A queue for Different Testing Responsibilities
- Linking to Any Forte Supported Test Configuration Product
Thank you,
Any additional questions please call or email me directly.
Joe Burns
Class I.Q.
610-254-5151
[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/>We have used JMETER from Apache foundation. This is more a stress test tool, but you can also use it for unit testing, as it allows you to record a serie of HTTP requests.
Since your question is not related to JHeadstart, you better post this question on the JDeveloper forum.
Steven DAvelaar,
JHeadstart team. -
Re: Forte and Dialup PPP connections
Subject: Forte and Dialup PPP connections
Priority: normal
Reply-to: "Dexel Durban" <[email protected]>
We want to run Win 95 on our client forte machines. Currently we're
using Forte v2.0E and MS TCP/IP.
Everything works fine in the LAN enviroment, however these client
machines have to run at remote sites, and therefore will need to use
modems with dialup PPP links.
The catch with the dialup procedure is that they will dial into a box
which verifies their username/password and then dials them back (for
security reasons) and sets up the PPP conection.
The only software that seems capable of setting up a PPP connection
after someone dialing your machines, is a product called Fastlink which
we're using.
After we've set up the PPP connection and run forte it works 100%,
however if we come out and run forte again - it can't establish the
connection to the host.
What we've deduced from this is that possibly :
1) MS TCP/IP isn't cleaning up after itself after the first
connection
2) The problem lies with Fastlinks ODI driver.
My questions are :
1) Has anyone managed to get forte running over a modem using PPP,
with the call-back verification procedure outlined above ?
2) In the Forte doc's it says that Forte is only compatible with Win
95 and MS TP/IP no other TCP/IP stack - is this true, or has someone
managed to get another stack working ?
Any help would be greatly appreciated !
- Carl
I have some similiar problems that basically were solved by a fix to one of the
ip executables. For this particular situations I was using Lan Workplace for DOS
Version 5 and just visited their web site and looked for a description similiar
to the problem I was having to determine the right patch. It sounds like when
you let go of your connection that the com port is probably still being held and
not beig released. I could be wrong but.... are you getting any other type of message?Thank you for your answer, David.
We are considering the splitting of one VMS partition into several ones to
streamline some functionality. Currently the communication between the
implied components is handled within the existing partition. By splitting it
we are expecting some performance loss due to interpartition communication
overhead and, since the number of messages expected will be high, we were
wondering if they will be needlessly going through the whole network stack
or transferred directly via socket IPC, as can be done in the Unix boxes.
The answer would help us tune-up the system by focusing at the right
parameters during testing of the new setup.
Alberto Lamas
Datamed SA -
We have no problem using JDK 1.1.5. However, we are using Orbixweb. If
you are accessing the applet and the IOR file from the same host (exact
host name), then one other possibility is the JVM compatibility for your
browser. Using Javasoft's Activator or appletviewer should resolve
that.
-----Original Message-----
From: Kamran Amin [SMTP:[email protected]]
Sent: Tuesday, March 10, 1998 7:48 AM
To: '[email protected]'; '[email protected]'
Subject: RE: Java and Forte
Dan,
We had the same problem as you are having regarding question
one. Make
sure you are
using JDK 1.1.3 or 1.1.4. It did not work for me when I was using JDK
1.1.5. Also you have to
use the gatekeeper to make the applet work. Hope this help.
Kamran Amin
Forte Technical Leader, Software Engineering
[email protected]
203-459-7362
Oxford Health Plans
48 Monroe Turnpike
CT, Trumbull 06611
http://www.oxhp.com/
From: [email protected][SMTP:[email protected]]
Sent: Monday, March 09, 1998 7:49 PM
To: [email protected]
Subject: Re: Java and Forte
1. I have been able to make my Java client appllication call-in to a
Forte service object with success. However the tricky part beginswhen
I try to do the same with a Java applet. I get an exception returned
which is an AppletSecurityException. I understand that running a Java
applet in a browser has two limitations, one being the Java applet
sandbox and the firewall restriction. As I am only running my Java
applet and the Forte service object on the same node, this rules out
the latter.
I have tried running the Gatekeeper from the same directory as myJava
client application, which includes all the client stub files
(including stub files which are generated from Forte supplier plans
such as those in the Framework folder). However, I still receive the
AppletSecurityException.
How can I go about making this operation successful?
**AppletSecurityExceptions can be caused by many problems--trying toaccess
machines other than the class download machine, or trying to accessserver
side classes outside the defined directory structure in the webserver. I'd
look closely at the classes that are being brought into memory (forexample,
Visibroker's ORB shows you each file as it is loaded) and make sureyour web
server is defined correctly. If you follow the Forte technotesclosely, it
usually solves this problem.
2. Has anyone tried implementing a 'fat' client, one that combines a
Forte web application, JavaScript, and a Java applet client toperform
operations such as validation and a tiny bit of data processing allon
the client side, relieveing the application server from such
operations? If yes, how do I implement the solution, and are thereany
tech notes from Forte that specifically tell me how to do this?
**We have created a Java framework that follows many of the designpatterns
and naming conventions as our Forte framework. The Java classes canbe
extended to marshal and unmarshal scalar data structs passed acrossthe ORB
boundary to instantiate 'thick' functional objects on the client, andas much
processing and as many business rules as wanted can be developed inthe
client
Java objects.If you look at the exception information in the iiop manual it
discusses exteneded propties DefaultThrowsClause, ThrowsClause and
IsThrowable.
If you mark your exception class with IsThrowable it will show up in the
IDL as an exception. If you use either DefaultThrowsClause(project) or
ThrowsClause(method) you will get the appropriate raises in the idl.
This will cause the idl2java to produce code which will allow you to catch
the exception.
Tom.
At 09:41 AM 1/29/99 +0100, Giuseppe Sorce wrote:
>
Hi all,
I am currently working to an architecture to establish a communication
between a Forte' server and a Java client, using Visigenic's Visibroker and
IDL mode.
I have problems when I try to raise a Forte' exception from a method
invoked by the Java client; I would like the exception class
(ProductException) not to inherit from the class GenericException, because
the IDL I want to generate must have this structure:
exception ProductException {
string message;
Using this solution, the client application gets blocked waiting forever.
I am currently working with:
- Forte' 3.0.G.2 plus WebEnterprise 1.0.B
- JDK 1.1.5
- Visibroker 3.1
My question is: is it possible to raise an exception from the Forte' side
that is
compliant to the IDL mentioned above?
Of course it should be caught from the Java side.
Thank you in advance
Giuseppe Sorce
CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
tel. +39-011-3168736
fax +39-011-3168212
e-mail [email protected]
url http://www.csi.it
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/> -
RE: how can two Forte installtion communicate
Hi,
I have similar arrangement here but for "user acceptence test". However,
may I remind you that when some objects/codes got checked out --> overwrite
with new import --> integrate --> check out again. Some funny things ( I
would say corruption ) may happen. I have one time that a normal old piece
of code got compilation error and no one can find out why. The last resort
is that I deleted everything and start from scratch again. Then everything
works.
Thus, I would suggest that from time to time, you should start out with a
new repository instead of using it over and over again in this fashion.
Maybe you can archive the old one as a version backup.
Regards,
Peter Sham.
-----Original Message-----
From: Kalidindi, Ravi CWT-MSP [SMTP:[email protected]]
Sent: Tuesday, February 16, 1999 1:10 AM
To: 'Nick Delany'; 'Jim Rice'
Cc: [email protected]
Subject: RE: how can two Forte installtion communicate
Nick...
We have a similar situation here. We have about seven teams,
each
with their own repositories with interdependent code.
Let me give you a simple scenario to explain how you can
make it
work:
Problem
--Team A is responsible for projects 1,2,3 and use repository RepA
--Team B is responsible for projects 4,5,6 adn use repository RepB.
--Project 2 is a supplier plan to project 5 and project 3 is a
supplier plan
to project 6.
Solution
--each repository is reponsible for some projects and these projects
can be
changed only in that repository.
--each repository also has a workspace called "SlaveProjects"
--This workspace has all the projects that are needed but are not
developed
by this team.
--These projects are checked out so that no one else can change them
-- so, RepB's slaveProjects workspace will have projects 2 and 3
(and other
projects they need).
-- You can also password protect the slaveProjects workspace.
-- When team A thinks they have a new working(or atleast compilable)
"version" of projects 2 and 3, they can trigger of an fscript which
will
export the projects 1 and 2, possibly save it in version control.
-- team B can then trigger another fscript which will pull the code
from
version control, import the projects 1 and 2 into RepB's
slaveProjects
workspace, integrate it and recheck everything out.
Options
-- you can get fancy with the scripts
-- you can add the two scripts together to do the whole thing in one
shot.
However existense of many such repositories can cause integrate
failures and
you might not know where exactly it stopped. You need to log the
output to
keep track.
-- you should probably make the second script actually create a
temporary
workspace, and import projects there and integrate. This is in case
you had
many other projects in the slaveprojects workspace that need not be
integrated and rechecked out each time.
-- you could create an application in forte or VB etc.. to make this
process
more sophisticated.
Hope that gives you a start. Different locations definetly
adds more
complexity to this, but the concept should be the same. If you have
more
questions or need more help, I suggest you call Len Lopez at
612-594-2539
who has played around with this stuff a lot. He put in place a VB
app that
does most of the stuff for us and will probably make a presentation
at the
Forte Forum this year on the same topic.
Good Luck!
-Ravi Kalidindi
Born Info Svcs Group.
> -----Original Message-----
> From: Nick Delany [SMTP:[email protected]]
> Sent: Monday, February 15, 1999 10:27 AM
> To: 'Jim Rice'
> Cc: [email protected]
> Subject: RE: how can two Forte installtion communicate
>
>
> Jim,
>
> Rajiv may not be referring to scenario 1, but I'm involved in
something
> like
> that.
> We're a bi-located team, and while we are trying to split up the
work to
> minimise the geographical dependancies, I'd be interested in
anything you
> might have to say about the best way to share code/repositories.
>
> Nick
>
> -----Original Message-----
> From: Jim Rice [mailto:[email protected]]
> Sent: 08 February 1999 22:38
> To: Rajiv Srivastava
> Cc: [email protected]
> Subject: Re: how can two Forte installtion communicate
>
>
> Rajiv,
>
> Can you elaborate ? I can see your questions leading toward at
least the 3
> following scenarios....
>
> 1. Are you asking about 2 different independent developer groups
which
> have
> only the internet as a possible connection pipe between them,
> or
> 2. Are you asking about 2 deployed applications which are the same
> application but deployed to environment production1 and redeployed
to
> environment production2
> or
> 3. Are you asking about 2 deployed applications whic are different
> applications and each is deployed to either
> 3a. a common deployment environment using the same
"Forte_NS_ADDRESS"
> 3b. two seperate deployment environements using the different
> "Forte_NS_ADDRESS" and therefore may even be on sepearte LAN/WAN's
>
> -Jim
>
> At 11:33 AM 2/8/99 , Rajiv Srivastava wrote:
> >Can somebody tell me that what r the possible way where two
different
> >independent Forte Installation can communicate to each other.
> >and share certain the information.
> >
> >thanking you in anticipation.
> >
> >Rajeev
> >
> >-
> >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 Rice mailto:[email protected]
> Partner ConCall @ Feb 17
> http://www.forte.com/events/frameset_partners.html
> Forte Usr Mtg @ May9-12 http://forum99.forte.com
> Partner Tech Specialist Work#: 301-721-1910
>
> -
> 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/>
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/>Hi,
I have similar arrangement here but for "user acceptence test". However,
may I remind you that when some objects/codes got checked out --> overwrite
with new import --> integrate --> check out again. Some funny things ( I
would say corruption ) may happen. I have one time that a normal old piece
of code got compilation error and no one can find out why. The last resort
is that I deleted everything and start from scratch again. Then everything
works.
Thus, I would suggest that from time to time, you should start out with a
new repository instead of using it over and over again in this fashion.
Maybe you can archive the old one as a version backup.
Regards,
Peter Sham.
-----Original Message-----
From: Kalidindi, Ravi CWT-MSP [SMTP:[email protected]]
Sent: Tuesday, February 16, 1999 1:10 AM
To: 'Nick Delany'; 'Jim Rice'
Cc: [email protected]
Subject: RE: how can two Forte installtion communicate
Nick...
We have a similar situation here. We have about seven teams,
each
with their own repositories with interdependent code.
Let me give you a simple scenario to explain how you can
make it
work:
Problem
--Team A is responsible for projects 1,2,3 and use repository RepA
--Team B is responsible for projects 4,5,6 adn use repository RepB.
--Project 2 is a supplier plan to project 5 and project 3 is a
supplier plan
to project 6.
Solution
--each repository is reponsible for some projects and these projects
can be
changed only in that repository.
--each repository also has a workspace called "SlaveProjects"
--This workspace has all the projects that are needed but are not
developed
by this team.
--These projects are checked out so that no one else can change them
-- so, RepB's slaveProjects workspace will have projects 2 and 3
(and other
projects they need).
-- You can also password protect the slaveProjects workspace.
-- When team A thinks they have a new working(or atleast compilable)
"version" of projects 2 and 3, they can trigger of an fscript which
will
export the projects 1 and 2, possibly save it in version control.
-- team B can then trigger another fscript which will pull the code
from
version control, import the projects 1 and 2 into RepB's
slaveProjects
workspace, integrate it and recheck everything out.
Options
-- you can get fancy with the scripts
-- you can add the two scripts together to do the whole thing in one
shot.
However existense of many such repositories can cause integrate
failures and
you might not know where exactly it stopped. You need to log the
output to
keep track.
-- you should probably make the second script actually create a
temporary
workspace, and import projects there and integrate. This is in case
you had
many other projects in the slaveprojects workspace that need not be
integrated and rechecked out each time.
-- you could create an application in forte or VB etc.. to make this
process
more sophisticated.
Hope that gives you a start. Different locations definetly
adds more
complexity to this, but the concept should be the same. If you have
more
questions or need more help, I suggest you call Len Lopez at
612-594-2539
who has played around with this stuff a lot. He put in place a VB
app that
does most of the stuff for us and will probably make a presentation
at the
Forte Forum this year on the same topic.
Good Luck!
-Ravi Kalidindi
Born Info Svcs Group.
> -----Original Message-----
> From: Nick Delany [SMTP:[email protected]]
> Sent: Monday, February 15, 1999 10:27 AM
> To: 'Jim Rice'
> Cc: [email protected]
> Subject: RE: how can two Forte installtion communicate
>
>
> Jim,
>
> Rajiv may not be referring to scenario 1, but I'm involved in
something
> like
> that.
> We're a bi-located team, and while we are trying to split up the
work to
> minimise the geographical dependancies, I'd be interested in
anything you
> might have to say about the best way to share code/repositories.
>
> Nick
>
> -----Original Message-----
> From: Jim Rice [mailto:[email protected]]
> Sent: 08 February 1999 22:38
> To: Rajiv Srivastava
> Cc: [email protected]
> Subject: Re: how can two Forte installtion communicate
>
>
> Rajiv,
>
> Can you elaborate ? I can see your questions leading toward at
least the 3
> following scenarios....
>
> 1. Are you asking about 2 different independent developer groups
which
> have
> only the internet as a possible connection pipe between them,
> or
> 2. Are you asking about 2 deployed applications which are the same
> application but deployed to environment production1 and redeployed
to
> environment production2
> or
> 3. Are you asking about 2 deployed applications whic are different
> applications and each is deployed to either
> 3a. a common deployment environment using the same
"Forte_NS_ADDRESS"
> 3b. two seperate deployment environements using the different
> "Forte_NS_ADDRESS" and therefore may even be on sepearte LAN/WAN's
>
> -Jim
>
> At 11:33 AM 2/8/99 , Rajiv Srivastava wrote:
> >Can somebody tell me that what r the possible way where two
different
> >independent Forte Installation can communicate to each other.
> >and share certain the information.
> >
> >thanking you in anticipation.
> >
> >Rajeev
> >
> >-
> >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 Rice mailto:[email protected]
> Partner ConCall @ Feb 17
> http://www.forte.com/events/frameset_partners.html
> Forte Usr Mtg @ May9-12 http://forum99.forte.com
> Partner Tech Specialist Work#: 301-721-1910
>
> -
> 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/>
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/> -
Re: Running the same (Forte) application multiple times -for different
Hi
We had the same problem - how to deploy a number of identical applications, using each their own db.
(for training).
The solution we used is to wrap the entire application into different applications by using a very small
module called KURSUS01, KURSUS02 etc, that did nothing but call the start procedure of the main app.
Then in the dbsession connect, we made a call appname to get the application name, and appended the
first 8 chars to the dbname. Thus our dbnames now points to logicals name: rdbdataKURSUS01, rdbdataKURSUS02 etc.
All this allows us to deploy the identical apps in the same env, or change one version, and run both the old
and new program on the same pc and server at the same time (eg. KURSUS01 and KURSUS02).
I also think this is a kludge - but it works nicely!
Jens Chr
KAD/Denmark
-----Original Message-----
From: Haben, Dirk <[email protected]>
To: 'Soapbox Forte Users' <[email protected]>
Date: 15. januar 1999 09:41
Subject: Running the same (Forte) application multiple times - for different business clients.
Hi All
We have a number of different business clients all willing to use our
application.
The (forte) application is to run on our machines etc for these (business)
clients.
All (business) clients will have their data kept in separate Oracle DBs
(instance).
The problem now is that the entire (forte) application is written using
DBSessions.
Now, depending on what business client needs to be serviced (so to speak) we
need to attach to the right DB - or use the "right" SO.
The two options we can think of are:
Option1:
Programatic change to somehow "know" what (business) client (DB) I'm talking
about and then use the right DB.
Pro:
Only one forte environment to maintain
Can run multiple (business) clients on same PC at the same time
Con:
Requires many program changes
bending O-O rules(?)
can't dynamically name SOs so can it be done at all? (ResourceMGRs maybe?)
Option2:
Use separate environments! One for each business client.
Pro:
More defined separation of app and data,
SLA-easy
Con:
Maintain "n" number of environments
Can only run the application for one environment (business client) at a time
on one PC - Big Negative here!
Not knowing any feasible solution to option 1 (without much code changes and
developer moaning) I would go for option two; as I have already worked on
multi-environment setups on VMS back at the Hydro (hi guys).
I would appreciate any comments from anyone who has solved this problem.
How, Why Pro Con etc.
TIA,
Dirk Haben
Perth, WA
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/>Hi
We had the same problem - how to deploy a number of identical applications, using each their own db.
(for training).
The solution we used is to wrap the entire application into different applications by using a very small
module called KURSUS01, KURSUS02 etc, that did nothing but call the start procedure of the main app.
Then in the dbsession connect, we made a call appname to get the application name, and appended the
first 8 chars to the dbname. Thus our dbnames now points to logicals name: rdbdataKURSUS01, rdbdataKURSUS02 etc.
All this allows us to deploy the identical apps in the same env, or change one version, and run both the old
and new program on the same pc and server at the same time (eg. KURSUS01 and KURSUS02).
I also think this is a kludge - but it works nicely!
Jens Chr
KAD/Denmark
-----Original Message-----
From: Haben, Dirk <[email protected]>
To: 'Soapbox Forte Users' <[email protected]>
Date: 15. januar 1999 09:41
Subject: Running the same (Forte) application multiple times - for different business clients.
Hi All
We have a number of different business clients all willing to use our
application.
The (forte) application is to run on our machines etc for these (business)
clients.
All (business) clients will have their data kept in separate Oracle DBs
(instance).
The problem now is that the entire (forte) application is written using
DBSessions.
Now, depending on what business client needs to be serviced (so to speak) we
need to attach to the right DB - or use the "right" SO.
The two options we can think of are:
Option1:
Programatic change to somehow "know" what (business) client (DB) I'm talking
about and then use the right DB.
Pro:
Only one forte environment to maintain
Can run multiple (business) clients on same PC at the same time
Con:
Requires many program changes
bending O-O rules(?)
can't dynamically name SOs so can it be done at all? (ResourceMGRs maybe?)
Option2:
Use separate environments! One for each business client.
Pro:
More defined separation of app and data,
SLA-easy
Con:
Maintain "n" number of environments
Can only run the application for one environment (business client) at a time
on one PC - Big Negative here!
Not knowing any feasible solution to option 1 (without much code changes and
developer moaning) I would go for option two; as I have already worked on
multi-environment setups on VMS back at the Hydro (hi guys).
I would appreciate any comments from anyone who has solved this problem.
How, Why Pro Con etc.
TIA,
Dirk Haben
Perth, WA
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/> -
How can two Forte installtion communicate - exactrequirement giv en at
To me, this clearly looks like a design issue. Here are two options that I
can think of:
1) You can achieve this through sql i.e. the sql service on location 1 can
allow you to query the database on location 2. Your service object uses the
user's criteria to decide which database to get to. This however is
inefficient since the dbsession is not on the same machine as the database.
2) Create a new layer ( umbrella ) which maintians a list of services that
register with it. This could be a seperate application and can be in a
seperate environment too. Your "database" service objects should also be
seperate applications. They register themselves to this layer. The remaining
part of your app should now be a seperate application which uses the "layer"
to get to the appropriate database. These different applications can talk to
each other using reference partitions accross connected environments.
Location 1 Location 2
app 1 app2
| |
(query the layer) (query the
layer)
| |
---------------------------------service
layer--------------------------------------------
|
(register self)
(register self)
|
database services 1 database services 2
I am sure there are more solutions to this problem. Others??
Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Rajiv Srivastava [SMTP:[email protected]]
Sent: Tuesday, February 09, 1999 11:45 AM
To: 'Kalidindi, Ravi CWT-MSP'
Subject: RE: [email protected]
Thnaks to yr reply:
Actual requirment is :
an Forte application running at Location 1 on Local Prodution data.
same application is running at Location2 with its own local data.
(both has their own separate resources) there is Network connectivity
available.
Now i wana to fire a query that can be done either way to retive some
information.
i.e. i should be able to retrive some data based on some criteria, from
location one while sitting at location 2. and vis-versa.
i think its clearly says what i want.
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 me, this clearly looks like a design issue. Here are two options that I
can think of:
1) You can achieve this through sql i.e. the sql service on location 1 can
allow you to query the database on location 2. Your service object uses the
user's criteria to decide which database to get to. This however is
inefficient since the dbsession is not on the same machine as the database.
2) Create a new layer ( umbrella ) which maintians a list of services that
register with it. This could be a seperate application and can be in a
seperate environment too. Your "database" service objects should also be
seperate applications. They register themselves to this layer. The remaining
part of your app should now be a seperate application which uses the "layer"
to get to the appropriate database. These different applications can talk to
each other using reference partitions accross connected environments.
Location 1 Location 2
app 1 app2
| |
(query the layer) (query the
layer)
| |
---------------------------------service
layer--------------------------------------------
|
(register self)
(register self)
|
database services 1 database services 2
I am sure there are more solutions to this problem. Others??
Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Rajiv Srivastava [SMTP:[email protected]]
Sent: Tuesday, February 09, 1999 11:45 AM
To: 'Kalidindi, Ravi CWT-MSP'
Subject: RE: [email protected]
Thnaks to yr reply:
Actual requirment is :
an Forte application running at Location 1 on Local Prodution data.
same application is running at Location2 with its own local data.
(both has their own separate resources) there is Network connectivity
available.
Now i wana to fire a query that can be done either way to retive some
information.
i.e. i should be able to retrive some data based on some criteria, from
location one while sitting at location 2. and vis-versa.
i think its clearly says what i want.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Question about creating libraries in Forte'
I'm looking into creating compiled libraries in Forte' to create a
"plug-and-play" interface among different implementation products. This
would allow us the ability to remove one library and upgrade it with
another assuming that the interfaces were the same. I'm using the
AddProjToLib to create a "super library" and am setting all of the
components as compiled. I am able to make the application distribution
with no problem. The problems that I am having are two-fold:
1) First auto-compile services cannot handle this "super project"
correctly. Don't get me wrong I HATE autocompile services but I decided to
give it a shot and see what happened. With that avenue gone, I went to
fcompile the individual libraries...these have to be done by supplier plan
order which is no big deal. The problem I ran into was that Forte' lower
cases all of the directory names, but the linker expected in some cases
that the directories would have some uppercase letters. The general rule
of thumb I found was that the directory name has to match the library name
generated. Forte' generated the library name with the proper letters
uppercase, but failed to do this to the directory structure. Obviously
this makes automating library creation a little more painful. This really
isn't a show stopper just a point I'd like to bring up in case and Forte'
people actually read these threads.
2) The major road block I ran into is the fact the Forte' statically
stores the full path of the libraries it is using during link/compilation
in the generated shared library. Forte's solution of just creating
symlinks (solution I found from their Technical Notes) is appalling at best
and does not support having multiple versions of libraries built from a
single installation running on the same machine (Unless you do simulated
environments to create a pseudo-new area...but I don't want to get into
that). Currently we are doing something extremely hoaky to solve this
problem with the few libraries that we have, but if we move to a more large
scale library solution this will not work.
I would love to hear any comments or suggestions about any of this. It is
sad that Forte' does not implement such a basic concept as SHLIB_PATH in
their shared libraries. By not doing this, it makes compiled libraries a
major hassle and potentially a waste of time.
Thanks for any comments that you might have in advance,
Scott Francis
Security First Technologies
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>I'm looking into creating compiled libraries in Forte' to create a
"plug-and-play" interface among different implementation products. This
would allow us the ability to remove one library and upgrade it with
another assuming that the interfaces were the same. I'm using the
AddProjToLib to create a "super library" and am setting all of the
components as compiled. I am able to make the application distribution
with no problem. The problems that I am having are two-fold:
1) First auto-compile services cannot handle this "super project"
correctly. Don't get me wrong I HATE autocompile services but I decided to
give it a shot and see what happened. With that avenue gone, I went to
fcompile the individual libraries...these have to be done by supplier plan
order which is no big deal. The problem I ran into was that Forte' lower
cases all of the directory names, but the linker expected in some cases
that the directories would have some uppercase letters. The general rule
of thumb I found was that the directory name has to match the library name
generated. Forte' generated the library name with the proper letters
uppercase, but failed to do this to the directory structure. Obviously
this makes automating library creation a little more painful. This really
isn't a show stopper just a point I'd like to bring up in case and Forte'
people actually read these threads.
2) The major road block I ran into is the fact the Forte' statically
stores the full path of the libraries it is using during link/compilation
in the generated shared library. Forte's solution of just creating
symlinks (solution I found from their Technical Notes) is appalling at best
and does not support having multiple versions of libraries built from a
single installation running on the same machine (Unless you do simulated
environments to create a pseudo-new area...but I don't want to get into
that). Currently we are doing something extremely hoaky to solve this
problem with the few libraries that we have, but if we move to a more large
scale library solution this will not work.
I would love to hear any comments or suggestions about any of this. It is
sad that Forte' does not implement such a basic concept as SHLIB_PATH in
their shared libraries. By not doing this, it makes compiled libraries a
major hassle and potentially a waste of time.
Thanks for any comments that you might have in advance,
Scott Francis
Security First Technologies
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
How can i run a program outside of Forte? (Forte and java/class files)
im making a program with forte... and i have a bunch of class files, i form file and a java file... how can i put these in one file so poeple without forte can run it...
thanksjmburns wrote:
I am trying to do a silent install of a program I built using LabVIEW 8.5. I also need to call an exe after the installation, so I am using the "run executable after installation" option on the Advanced tab of the installer. I then pass the following command lines to the setup.exe:
/qb /acceptlicenses yes /r
This installs the LabVIEW program successfully, but does not then run the additional exe afterward. If I run the setup.exe normally (with no command line parameters), the additional exe gets run.
Thanks,
Jason
This problem is fixed in a future release of LabVIEW. Here's the CAR ID 67549 for tracking purposes.
Message Edited by Bob P on 07-10-2008 09:10 AM -
Creating Forte FieldWidgets Dynamically at Runtime
Hi Everyone,
Could someone please help me with the following problem I have when
creating Forte fieldwidgets dynamically at run-time. I am using Forte
ver. 3.0.G.2.
(-1-) I have a window class with an empty gridfield, <grfMain>, inside a
viewport. The idea is to populate the gridfield with DataField
fieldwidgets dynamically at runtime. Depending on some input criteria,
sometimes some of the DataFields need to map to IntegerNullables, some
to DoubleNullables and some to DateTimeNullables. (Please note that I
cannot use the Forte window workshop to create these fieldwidgets,
because different types of fieldwidgets will be needed at different
times, in different numbers, at run-time. ) Here is a sample of how I am
currently trying to achieve this:
dfDate : DataField = new;
dfDate.MaskType = MK_Template;
dfDate.DateTemplate = new( value='dd/mm/yyyy' );
dfDate.Row = 1;
dfDate.Column = 2;
dfDate.Parent = <grfMain>;
dfInt : DataField = new;
dfInt.MaskType = MK_INTEGER;
dfInt.Row = 2;
dfInt.Column = 2;
dfInt.Parent = <grfMain>;
dfReal : DataField = new;
dfReal.MaskType = MK_FLOAT;
dfReal.Row = 3;
dfReal.Column = 2;
dfReal.Parent = <grfMain>;
The code above is called after the window has been opened with the
Open() statement.
Looking at the code above, one obvious omission is that the "Mapped
Type" of the Datafields are not set up. In the Forte window workshop, an
interface is provided to set up the "Mapped Type" of the Datafield
widgets, but I'm not sure how to do that dynamically, and that is
basically my biggest problem here.
(-2-) If I now run the window class, the Datafield widgets get created,
and they all have the correct input maks, but no validation gets done
when one tabs away from the field. For example, Datafields with
MaskType=MK_INTEGER will gladly accept '--1--0++7', while Datafields
created in the window workshop (mapping to IntegerNullables) will do a
validation, and not allow one to tab out of the field before the extra
minus and plus signs are not removed.
I have the same problem with the Datafields which have
MaskType=MK_Template and DateTemplate='dd/mm/yyyy'. For the date, one
can enter something like '2*\**\****', and leave the field, while the
same type of datafield created in the window workshop (mapped to a
DateTimeNullable), will not allow you to leave the field before a valid
date has not been entered. To summarise, the input masks of my
dynamically created Datafields work fine, but no validation gets done
when the field looses the focus.
(-3-) As a test, I used the Forte debugger ("view"-"local variables") to
look at the differences between Datafields created dynamically, and
those created in the Forte window workshop. One very obvious difference
was that Datafield attribute "MapTypeName" was filled in for the window
workshop Datafields, but not for my dynamically created Datafields. The
problem is that Forte does not allow me to set this attribute
dynamically in my code. How else can I setup the Mapped Type
dynamically?
(-4-) In order to have a consistent look-and-feel throughout our Forte
project, we are making use of Domain classes for DATE and DECIMAL data
entry fields. My questions are:
(4.1) How must I go about creating Datafields dynamically that make use
of these Domain classes?
(4.2) Is it also a matter of setting up the "MapTypeName" attribute,
which I cannot seem to do?
(4.3) Is the mapping done differently for Domain classes?
(-5-) Another interesting thing to note for Datafields created in the
Forte Window Workshop, is that if the mapped type is IntegerNullable
with Input Mask = Integer, or DoubleNullable with Input Mask = Float,
then the Object that the Datafield widget maps to, must first be
instantiated before the Loose-Focus validations will start to work. For
example, if a Datafield widget called "dfTestInt" was created in the
Forte window workshop, which maps to an IntegerNullable, and Input Mask
= Integer, then the following line is needed before the window is
displayed: dfTestInt = new;
Without this line, one can enter something like '2---3+++7', and leave
the field.
This is not true for Datafields where the mapped type is
DateTimeNullable with say Input Mask Template='dd\mm\yyyy'. In this case
validations are done even thought the object being mapped to, has not
been instantiated yet. In other words you will never be able to enter
'2*/**/****', and leave the field for datafield created in the window
workshop. Maybe in this case the validation is being done by the
template itself?
Thanks in advance
Riaan
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>what I mean is rendering JSF components on the fly, becuase some time you don't know things at design time. Lets say I am designing a page in creator that shows the total number of dependants that belongs to a primary inusrance member in text boxes. Of course we don't know in advance how many dependants we have for a specific member unless we go to databse and fetch all the data at runtime. Desiging some thing dynamic like that is very easy in CGI or ASP/JSP but JSF model seems very static due to it's design time feature.
So is it possible with JSF or not?
Maybe you are looking for
-
Could not complete the smart sharpen command because there is not enough memory (RAM)
Hi, I'm trying to complete the AutoSharpen (Filter->Sharpen->AutoSharpen) feature but, i'm getting the following error when i click on "Ok". Error in Dialogue Box "Could not complete the smart sharpen command because there is not enough memory (RAM)"
-
XMl report output error oracle.apps.xdo.template.fo.area.NoAvailableAreaExc
All, Here is the error I'm getting when AR invoice is printed in PD fformat. I dont see this issue for all invoices, I ahve this issue when invoice has 9 lines. oracle.apps.xdo.template.fo.area.NoAvailableAreaException: object = 'oracle.apps.xdo.temp
-
Custom Infotype - Overview Screen ( Screen 30000
Hi All, I have developed a custom infotype. Need some inputs regarding the overview/List screen Please ! the overview screen primarily is used to list the records for date ranges.i.e. every line / row will have a unique date range for which the recor
-
Error generating screen commentary files - OPM 10.2
Hi everyone, I'm getting an error generating a screen commentary files. Link to error: The commentary files could not be created. PLease ensure that your configuration settings are correct and you have write permission to the specified commentary dir
-
Erronerous offset in AI data on all channels
Hello! I'm using NI-6152 PCI multifunction DAQ card with BNC-2120 accessory. MAX using DAQmx 7.3 Up to now everything was OK. Today I have started the measurements and found the shift of the AI results on about 1V up. Then I have switched off all BNC