I am writing a trigger that will need to be able to pull what field the
user is currently on. With basic field-level objects, I can use FOCUS:NAME
or FOCUS:LABEL.
When I am on a dynCombo, FOCUS:NAME = "fiCombo" and FOCUS:LABEL = ? (this
presumably will also be the case for dyn-Lookup when the issue with
triggers in dynLookups is fixed-- I can't test it at this point though). I
need to be able to get something solid to identify one field from the
others, but can't figure how to get it. It needs to be something that
won't change between sessions.
If I could find the handle to the instance of the dynCombo procedure for
that field, I would be fine-- but can't figure how to get that...
Any ideas??
Thanks--
James
James Burts james@klas.com
Keystone Systems, Inc. 919-782-1143
Manager of Software Development Raleigh, NC
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
I'm using adm2 and this is how I do it. I have a function in a super
procedure. I didn't put the 'getContainerHandle' in the function put I
could have passed h_dynreason and done it in the function.
Hope that it works the same in dynamics.
hPrimary =
DYNAMIC-FUNCTION('getSelectHandle':U,DYNAMIC-FUNCTION('getContainerHandle':U
IN h_dynreason),'combo-box').
FUNCTION getSelectHandle RETURNS HANDLE
( INPUT i-select AS HANDLE, INPUT i-type AS CHAR ) :
ASSIGN i-select = i-select:FIRST-CHILD
i-select = i-select:FIRST-CHILD.
DO WHILE VALID-HANDLE(i-select):
IF i-select:TYPE = i-type
THEN RETURN i-select.
i-select = i-select:NEXT-SIBLING.
END.
RETURN ?.
END FUNCTION.
Miles
-Original Message-
Sent: Friday, 23 August 2002 12:15 AM
To: dev@icf.possenet.org
Subject: label for DynCombo??
I am writing a trigger that will need to be able to pull what field the
user is currently on. With basic field-level objects, I can use FOCUS:NAME
or FOCUS:LABEL.
When I am on a dynCombo, FOCUS:NAME = "fiCombo" and FOCUS:LABEL = ? (this
presumably will also be the case for dyn-Lookup when the issue with
triggers in dynLookups is fixed-- I can't test it at this point though). I
need to be able to get something solid to identify one field from the
others, but can't figure how to get it. It needs to be something that
won't change between sessions.
If I could find the handle to the instance of the dynCombo procedure for
that field, I would be fine-- but can't figure how to get that...
Any ideas??
Thanks--
James
James Burts james@klas.com
Keystone Systems, Inc. 919-782-1143
Manager of Software Development Raleigh, NC
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
DISCLAIMER
***********************************************************************
The information contained in this email and any attachments
are intended for the named recipient only. It may contain
privileged and confidential information, if you are not the
named recipient, you must not disclose, copy, distribute or
take any action in reliance on it. The legal privilege and
confidentiality attached to this email is not waived, lost
or destroyed by reason of a mistaken delivery to you. If you
have received this email in error, please notify the sender
and delete it from your computer and network. Unless stated
otherwise, this email represents the views of the sender and
not necessarily those of the RTA.
***********************************************************************
***********************************************************************
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
From what I can tell from the code you gave, it will return the handle to
the combo-box, given the handle of the dynamic combo box.
I need rather the opposite.
I've got the handle to the combo-box widget (it is the FOCUS handle when
the trigger I'm writing fires). The combo-box itself doesn't have a label
(FOCUS:label = ?). The handle to the combo-box widget doesn't help me much
in this case. What I'd like to get is the equivalent to your h_dynreason,
but I don't see how to get it with the starting point of the field level
combo-box widget.
Does this make any sense??
James
James Burts james@klas.com
Keystone Systems, Inc. 919-782-1143
Manager of Software Development Raleigh, NC
--On Friday, August 23, 2002 7:14 AM +1000 Miles Klettke
wrote:
I'm using adm2 and this is how I do it. I have a function in a super
procedure. I didn't put the 'getContainerHandle' in the function put I
could have passed h_dynreason and done it in the function.
Hope that it works the same in dynamics.
hPrimary =
DYNAMIC-FUNCTION('getSelectHandle':U,DYNAMIC-FUNCTION('getContainerHandle
':U IN h_dynreason),'combo-box').
FUNCTION getSelectHandle RETURNS HANDLE
( INPUT i-select AS HANDLE, INPUT i-type AS CHAR ) :
ASSIGN i-select = i-select:FIRST-CHILD
i-select = i-select:FIRST-CHILD.
DO WHILE VALID-HANDLE(i-select):
IF i-select:TYPE = i-type
THEN RETURN i-select.
i-select = i-select:NEXT-SIBLING.
END.
RETURN ?.
END FUNCTION.
Miles
-Original Message-
Sent: Friday, 23 August 2002 12:15 AM
To: dev@icf.possenet.org
Subject: label for DynCombo??
I am writing a trigger that will need to be able to pull what field the
user is currently on. With basic field-level objects, I can use
FOCUS:NAME or FOCUS:LABEL.
When I am on a dynCombo, FOCUS:NAME = "fiCombo" and FOCUS:LABEL = ? (this
presumably will also be the case for dyn-Lookup when the issue with
triggers in dynLookups is fixed-- I can't test it at this point though).
I need to be able to get something solid to identify one field from the
others, but can't figure how to get it. It needs to be something that
won't change between sessions.
If I could find the handle to the instance of the dynCombo procedure for
that field, I would be fine-- but can't figure how to get that...
Any ideas??
Thanks--
James
James Burts james@klas.com
Keystone Systems, Inc. 919-782-1143
Manager of Software Development Raleigh, NC
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
DISCLAIMER
***********************************************************************
The information contained in this email and any attachments
are intended for the named recipient only. It may contain
privileged and confidential information, if you are not the
named recipient, you must not disclose, copy, distribute or
take any action in reliance on it. The legal privilege and
confidentiality attached to this email is not waived, lost
or destroyed by reason of a mistaken delivery to you. If you
have received this email in error, please notify the sender
and delete it from your computer and network. Unless stated
otherwise, this email represents the views of the sender and
not necessarily those of the RTA.
***********************************************************************
***********************************************************************
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
James Burts james@klas.com
Keystone Systems, Inc. 919-782-1143
Manager of Software Development Raleigh, NC
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
I logged an issue with Tech support, but hope I can get a quick answer here
which will allow me to continue beta testing with our application upgraded
from v1.1SP3 to V2.
I suspect somewhere along the way a step has been missed either in the
definition of
the DLProc object type in our 1.1 repository, or in applying a noddy to
register DLProcs.
(Most of our SDO's were generated a long time ago.)
Although we are using Roundtable, I decided to procopy our existing
repository to a
separate beta test area, and upgrade it without Roundtable, just to keep
things simple.
The DCU performed the upgrade to 2.0 exactly as expected and without a
hitch. Aside
from manually modifying the supplied icfconfig.xml to put in the proper
connection
parameters (which perhaps the DCU could've/should've done for me) to the
LINUX database,
the initial dynamics startup worked fine, as well, except for an error 5893
related to having to register prox.dll which the knowledgebase explained was
something to do with upgrading the same minor version numbers of Progress ie
9.1C to 9.1D... This error came up after all the post-DCU fixes were applied
to the database, and I have assumed (perhaps wrongly) that it did not impact
the 1.1->2.0 Dynamics upgrade.
The problem I have right now, is that when I attempt to start the
application through the launcher, V2 gives me a message that the DLProc for
the menu has not been registered. When I open the procedure in AppBuilder
and select File->Register in Repository, there is no DLProc in the 'Object
Type' combo. (When I look in the Object type maintenance, DLProc is there,
but when I expand the tree view node, I get an error message.)
I thought it'd be easy to work around this, to manually add my DLProcs to
the repository,
but now I'm not sure what to do. So any guidance from you folks would be
appreciated.
TIA,
Tom Greenwood
DEGAMA Systems Inc.
http://www.degama.com
416-493-0059 x107
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org