Hi!

The 6.3 manual says regarding the field 179:

"A GUID is available during active link processing on the client and
through all filter phases."

I can't confirm that. I have a dialog type window (which is still a
regular form) on that I have a field with the ID 179, but I don't see any
value in the field 179. Even after saving the record, there is no GUID in
the field. Does it mean, the 179 field is useless on DIALOG type windows?
Is there a trick I can get the 179 field on a dialog to automatically
populate itself with a GUID, of course without using the Application-
Generate-GUID command?


Mark


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Mark,

Let me first try to set some terminology straight.

ARS Form "windows" do not have types, but they do have modes. ARS
client window modes are a subset of all ARS $OPERATION$ values.

$OPERATION$ value [Form Mode related to OPERATION]
-------------------------------
-----------------------------------------------------
CREATE [New]
DIALOG [Dialog]
GET [Display]
QUERY [Search]
SET [Modify]
SET ALL [Modify All]

However the full $OPERATION$ list also includes DELETE, and MERGE,
which do not have corresponding "client window mode" values.

However as a bit of a side note there is a Form Mode that does not map
to any OPERATION too. It is currently called "Display". (In the older
terminology it was called "Display Only". An mode that set all fields
to "Read Only" automatically, but you could still use active links
attached to trim like buttons.) However this always was a bit of a
"hack", convenient but still a hack, as it is only an ARS client
concept. (However, now that the OLE interface exists it is less than
helpful.)


It is very easy to see how these concepts are a bit confusing too. :)


Only specific (New, Search, Modify) window modes inherently trigger
filter activity when the user "completes" the activity with the ARS
client "save" button. However, all ARS forms could have active links
on them. Those active links could trigger an activity that would "use"
an ARS form in a different mode than the users current window is
operating in. (A Push action could do a Submit or a Modify operation
from a Dialog form for example.)


So... back to the specific details about field 179....

I think the docs are very unclear about when this field is exactly set
with a value. So I have to guess a bit. (or do some testing)

My bet is that this field is set during Set Defaults, or more likely
during Window Loaded/Display processing in the Remedy clients. The rub
here is that these sets of active links are not fired for a window
opened in DIALOG mode. (Set Defaults might, optionally be fired if the
Window Open action requests it only for a Submit, or Search mode
window, but not for Dialog.)



However you could choose to either:

1) generate (Application-Generate-GUID) a value and pass it into the
dialog window during the Window Open action (via the "On Open"
mapping) that you call to open the DIALOG.

OR

2) Have an active link on Window Open
generate(Application-Generate-GUID) the value.

It kind of depends on when you need the value set for the Dialog. You
might even need to "re-set" the value over the life cycle of the
DIALOG. For example, if the dialog is a control panel that users use
to submit multiple records over a period of hours. It would likely be
necessary for you to generate a new value between calls. And your
active links can do that easily.


Is there some reason your opposed to creating this value with an Active Link?

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.


On 12/19/05, Mark Milke wrote:
> Hi!
>
> The 6.3 manual says regarding the field 179:
>
> "A GUID is available during active link processing on the client and
> through all filter phases."
>
> I can't confirm that. I have a dialog type window (which is still a
> regular form) on that I have a field with the ID 179, but I don't see any
> value in the field 179. Even after saving the record, there is no GUID in
> the field. Does it mean, the 179 field is useless on DIALOG type windows?
> Is there a trick I can get the 179 field on a dialog to automatically
> populate itself with a GUID, of course without using the Application-
> Generate-GUID command?
>
>
> Mark


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Man, you got that right!

The docs refer to field ID 179 as if it magically creates a GUID by virtue of
its mere existence. Well, I've *never* gotten a GUID to appear in a 179 field
without some workflow actively creating it. However, I have to confess I
stopped trying when I saw that Remedy CS 5.6 calls Application-Generate-GUID
every time it needs to create a GUID. (And it creates GUIDs all the time, two
or three for every form entry, whether it makes sense or not!)

If Remedy development resorted to the "workflow extra" $PROCESS$ set fields
command, then I suppose I'm in good company.

--Tim


--- Carey Matthew Black wrote:

> Mark,
--- snip ---
>
> So... back to the specific details about field 179....
>
> I think the docs are very unclear about when this field is exactly set
> with a value.
--- snip ---


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Hi!

>Is there some reason your opposed to creating this value with an Active
>Link?

BasicGuide 6.3 Page 239:

"Note: Prior to AR System 6.3, you used the $PROCESS$ command to generate
GUIDs. Using a GUID field provides better performance than the
$PROCESS$ command."

I thought, if the field creates the GUID for me by its mere existance and
provides better performance on top of that, why should I bother creating
workflow?

Mark


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Tim,

>The docs refer to field ID 179 as if it magically creates a GUID by
>virtue of its mere existence. Well, I've *never* gotten a GUID to appear
>in a 179 field without some workflow actively creating it.

The only case when the field with the ID 179 kind of "works", i.e. creates
the GUID by its mere existence, is, when you open a window in submit mode
and save a record. You won't be able to see nor access the GUID however
until the record is saved, but you will see it in the new record created.
If I got the documentation right, the field with the id 179 doesn't work
as intended!

>However, I have to confess I
>stopped trying when I saw that Remedy CS 5.6 calls Application-Generate-
>GUID every time it needs to create a GUID. (And it creates GUIDs all the
>time, two or three for every form entry, whether it makes sense or not!)

Well, the manual claims:

"Prior to AR System 6.3, you used the $PROCESS$ command to generate
GUIDs.
Using a GUID field provides better performance than the $PROCESS$ command."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Mark


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

You're absolutely right. But in CS 5.6, for example, they want a GUID to be
available as soon as you open a new (submit) window. That's reasonable. If an
entry ID/request ID doesn't exist yet, and you want to uniquely identify the
current transaction, a GUID is just what the doctor ordered.

It's as if the backend development guys tossed it over the wall to the
application development team and said, "Here's what you wanted." But... No,
it's not.

--Tim


--- Mark Milke wrote:

> Tim,
>
> >The docs refer to field ID 179 as if it magically creates a GUID by
> >virtue of its mere existence. Well, I've *never* gotten a GUID to appear
> >in a 179 field without some workflow actively creating it.
>
> The only case when the field with the ID 179 kind of "works", i.e. creates
> the GUID by its mere existence, is, when you open a window in submit mode
> and save a record. You won't be able to see nor access the GUID however
> until the record is saved, but you will see it in the new record created.
> If I got the documentation right, the field with the id 179 doesn't work
> as intended!
>
> >However, I have to confess I
> >stopped trying when I saw that Remedy CS 5.6 calls Application-Generate-
> >GUID every time it needs to create a GUID. (And it creates GUIDs all the
> >time, two or three for every form entry, whether it makes sense or not!)
>
> Well, the manual claims:
>
> "Prior to AR System 6.3, you used the $PROCESS$ command to generate
> GUIDs.
> Using a GUID field provides better performance than the $PROCESS$ command."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Mark
>
>

> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Listians,

Can someone explain why the field size for the Unique Identifier core field
is 38, but the Unique Identifier generated by $PROCESS$
Application-Generate-GUID is 30?

I know there's probably some good obscure reason for this, but it has
escaped me. 30 would be the historic length of just about anything in
Remedy, but why 38......?

Just a small rant, and Dan wanted some traffic :-)

HNY!

Doug


Doug Blair
Remedy Skilled Professional
dougblairingcom
+1-224-558-5462

via wireless PDA


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

**
Hey Doug,

Good question. Just an educated guess... they allowed room in case someone wanted to add a prefix for whatever reason.

Kelly
---------------------
Kelly Deaver
Director, ITSM Practice
Xinify
kelly.deaver@xinify.com




-------- Original Message --------
Subject: Field 179
From: Doug Blair
Date: Fri, December 30, 2005 3:47 pm
To: arslist@ARSLIST.ORG

Listians,

Can someone explain why the field size for the Unique Identifier core field
is 38, but the Unique Identifier generated by $PROCESS$
Application-Generate-GUID is 30?

I know there's probably some good obscure reason for this, but it has
escaped me. 30 would be the historic length of just about anything in
Remedy, but why 38......?

Just a small rant, and Dan wanted some traffic :-)

HNY!

Doug


Doug Blair
Remedy Skilled Professional
dougblairingcom
+1-224-558-5462

via wireless PDA


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

This posting was submitted via the Web interface

**
My suspicion is that there are GUID generation routines that can be as long as 38 characters long in some instances and hence the extra space to accommodate that possibility.

HTH
--
Shyam

----- Original Message -----
From: Kelly Deaver
Newsgroups: gmane.comp.crm.arsystem.general
Sent: Friday, December 30, 2005 3:52 PM
Subject: Re: Field 179

**
Hey Doug,

Good question. Just an educated guess... they allowed room in case someone wanted to add a prefix for whatever reason.

Kelly
---------------------
Kelly Deaver
Director, ITSM Practice
Xinify
kelly.deaver@xinify.com




-------- Original Message --------
Subject: Field 179
From: Doug Blair
Date: Fri, December 30, 2005 3:47 pm
To: arslist@ARSLIST.ORG

Listians,

Can someone explain why the field size for the Unique Identifier core field
is 38, but the Unique Identifier generated by $PROCESS$
Application-Generate-GUID is 30?

I know there's probably some good obscure reason for this, but it has
escaped me. 30 would be the historic length of just about anything in
Remedy, but why 38......?

Just a small rant, and Dan wanted some traffic :-)

HNY!

Doug


Doug Blair
Remedy Skilled Professional
dougblairingcom
+1-224-558-5462

via wireless PDA


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

This posting was submitted via the Web interface

This posting was submitted via the Web interface