I also use a local character field when showing an image in a table field. In the example below the field in the 'Visible' column is a local character field:
[image: Inline image 2] If I used the remote selection field that controls the images as the 'Visible' column it would show the text selection values along with the image. Jason On Wed, Dec 10, 2014 at 9:12 AM, LJ LongWing <[email protected]> wrote: > ** > when you are looping through the table, you are setting the column to the > value you want it to be...the display only field is just a 'holder' to be > able to make it a column...but yes, when on the row, and you do a setfield > to that column, it stays there, in theory, till the table is refreshed. > > On Wed, Dec 10, 2014 at 10:04 AM, Charlie Lotridge <[email protected]> > wrote: > >> ** >> So LJ or Fred, are you saying that when using display field as a column, >> then set it during a table walk, the client will maintain the individual >> values for each row? This would effectively make the display field it an >> array? >> >> I'm probably misunderstanding, but if this is the case then having such a >> "client side array" mechanism would open up all kinds of possibilities to >> me. It would be fascinating. >> >> On Wed, Dec 10, 2014 at 8:46 AM, Grooms, Frederick W < >> [email protected]> wrote: >> >>> ** >>> >>> I use it >>> >>> >>> >>> I have a list view table of values with a selection column that the user >>> can double click to flag (sort of a multi-select menu). That column is >>> mapped to a local display only field. >>> >>> On save I use an AL Guide to walk the table to collect the flagged rows. >>> On Display I use a different guide to set the local display only field >>> so the users can see what was selected >>> >>> >>> >>> Fred >>> >>> >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *Charlie Lotridge >>> *Sent:* Wednesday, December 10, 2014 10:31 AM >>> *To:* [email protected] >>> *Subject:* Re: need some ideas from you how to show incidents >>> recordsover4hrinred color. >>> >>> >>> >>> ** >>> >>> LJ, you'd brought up a point that's been an outstanding question for me, >>> and since we're on the topic... >>> >>> >>> >>> Why do display fields from the local form appear as options for columns >>> for a table? I've never used this "feature" and don't quite know what it's >>> for. >>> >>> >>> >>> Anyone use this? And if so how & why? >>> ------------------------------ >>> >>> On Wed, Dec 10, 2014 at 8:12 AM, LJ LongWing wrote: >>> >>> ** >>> >>> Sorry...forgot to credit the source of the 2 ideas I said were still in >>> play :) >>> ------------------------------ >>> >>> On Wed, Dec 10, 2014 at 9:09 AM, Charlie Lotridge wrote: >>> >>> ** >>> >>> Hmmm...let's see... >>> >>> >>> >>> Yeah, I'll vote for option number 1! ;) >>> >>> >>> >>> -c >>> ------------------------------ >>> >>> On Wed, Dec 10, 2014 at 7:34 AM, LJ LongWing wrote: >>> >>> ** >>> >>> Ok....so, I decided to spend some time playing with this this morning >>> and ended up putting together a functional prototype, but I wouldn't >>> implement this prototype in a production environment because of the >>> client/server/network overhead associated....and I learned something new :) >>> >>> >>> >>> So...the 'new' thing that I learned is that when setting color of a >>> table field, the field must be on the source form, not a display only on >>> the current form...this is important because the field must be set at time >>> of 'refresh' of the table to set the color....so, this negates the loop >>> through the table with AL Guide...except in the prototype I built...where >>> the loop through the table causes a push to the backend form, and then a >>> second refresh....so, each record in the table is queried once, then >>> updated with a color, then queried again....as you can imagine, this gets >>> very 'heavy' from a performance perspective....so...after all of this is >>> said and done, I think there are only two options truly in play >>> >>> >>> >>> 1 - View form that calculates the color automatically in a DB view >>> without any Remedy workflow >>> >>> 2 - JavaScript magic >>> >>> >>> >>> The other options, as explored seem to either not work, or are too >>> resource intensive. >>> ------------------------------ >>> >>> On Tue, Dec 9, 2014 at 11:13 PM, Omega LiPO wrote: >>> >>> ** >>> >>> Hi Charlie, >>> >>> Understood the case from you. So, I thought the AL field will work but >>> it doesn't. >>> >>> Long story shorts. I managed to "walk a table field and be set a value >>> to selection-field. But it does not change to the display value. I.e. >>> 0=Red, 1=Yellow. >>> So, even the value is set , I could not change the color. >>> >>> Anyone has an experience to walk-a-table fields in a selection-field of >>> a join form. Please let me know how. >>> >>> Thanks // Omega >>> ------------------------------ >>> >>> *From: *Charlie Lotridge <[email protected]> >>> *Sent: *10/12/14 7:01 AM >>> >>> >>> *To: *[email protected] >>> *Subject: *Re: need some ideas from you how to show incidents >>> recordsover4hrinred color. >>> >>> ** >>> >>> Omega, >>> >>> >>> >>> I've run a quick test and as I suspected the ARGetListEntryWithFields >>> API is used to fill the table upon refresh, and it does NOT trigger the Get >>> Entry filters of the entries retrieved. >>> >>> >>> >>> If you're interested, I've attached the form & filters I used for the >>> test. Similar to your own requirement, the Get Entry filters will simply >>> set a Display type selection field called 'Color Status' to "Very Old" if >>> the entry was modified more than 5 minutes ago, "Old" if it was modified >>> more than 3 minutes ago, otherwise "New". >>> >>> >>> >>> Load these defs then add a few entries over the course of the next 5 >>> minutes or so. Run a normal search list and move through them entry by >>> entry, running a filter log, to see that the Get Entry filters do in fact >>> run (which is also evident since the 'Color Status' is being set). >>> >>> >>> >>> Then refresh the table while running a filter log and you will NOT see >>> any of the filters being run. >>> >>> >>> >>> I think you'll need to consider one of the other solutions. >>> >>> >>> >>> -charlie >>> ------------------------------ >>> >>> On Tue, Dec 9, 2014 at 4:16 AM, Omega LiPO wrote: >>> >>> ** >>> >>> Thanks. I knew the enable/disable filter log at server side and client. >>> >>> However, I did not get the time to test today. I got a weird ideas to >>> use on display active link to set the fields, and will try it tmr, to see >>> if it can set the display-field under the table-field. Which I think it >>> might works. >>> >>> And will let you all knew the result. . >>> >>> Thank you // Omega >>> ------------------------------ >>> >>> *From: *Charlie Lotridge <[email protected]> >>> *Sent: *9/12/14 12:29 PM >>> >>> >>> *To: *[email protected] >>> *Subject: *Re: need some ideas from you how to show incidents records >>> over4hrinred color. >>> >>> ** >>> >>> Omega, >>> >>> >>> >>> Here's a link >>> <https://docs.bmc.com/docs/display/public/ars81/Enabling+logs+for+performance+issues> >>> to relevant documentation on server side logging. I'm not quite clear on >>> what you did not get, but to be clear I do mean that you should turn on the >>> filter log, refresh the table, turn off the filter log, and examine the >>> results. If things are working as you want them to, then you should see >>> your Get Entry filter firing once for every entry retrieved in the table. >>> >>> >>> >>> This has actually got my curiosity peaked, so I'll probably try some >>> testing myself tomorrow, though do let me know what you discover (or does >>> someone else already know the answer...?). >>> >>> >>> >>> Thanks, >>> Charlie >>> ------------------------------ >>> >>> On Mon, Dec 8, 2014 at 2:40 PM, Omega LiPO wrote: >>> >>> ** >>> >>> Hi Charlie, >>> >>> How to do the filter-log ? You mean turn on the filter log. I did not >>> get it. >>> >>> Thanks, >>> Omega >>> ------------------------------ >>> >>> *From: *Charlie Lotridge <[email protected]> >>> *Sent: *9/12/14 5:53 AM >>> >>> >>> *To: *[email protected] >>> *Subject: *Re: need some ideas from you how to show incidents records >>> over 4hrinred color. >>> >>> ** >>> >>> Omega, run a filter log to make sure that the Get Entry filter is >>> actually firing on each entry when you load (refresh) the table. I know >>> that it'll fire when you access an individual entry on the source form >>> (which uses the ARGetEntry API), but the table data retrieval probably uses >>> the one of the APIs that retrieves multiple entries in a single call (e.g. >>> ARGetListEntryWithFields, ARGetMultipleEntries, ARGetListEntryBlocks). I'm >>> not sure if these will invoke the Get Entry filter on the individual >>> entries (and don't have time to test it myself right now). >>> >>> >>> >>> Hope this helps. >>> >>> >>> >>> -charlie >>> ------------------------------ >>> >>> On Mon, Dec 8, 2014 at 1:43 PM, Omega LiPO wrote: >>> >>> ** >>> >>> I found it out this morning . And try it out. If I open the joined form, >>> I see the color= can set to red or yellow. However, when I open the table >>> field of such fields using display only form , the value did not show. >>> Hmmm. I even set the filter order=0. I bet some ordering problem. >>> >>> Need more time to go testing tmr. Tks for your help. >>> >>> >>> Regards, >>> Omega >>> ------------------------------ >>> >>> *From: *Grooms, Frederick W <[email protected]> >>> *Sent: *9/12/14 5:26 AM >>> >>> >>> *To: *[email protected] >>> *Subject: *Re: need some ideas from you how to show incidents records >>> over 4hrin red color. >>> >>> ** >>> >>> It is just a filter set to fire on Get Entry of your form. This filter >>> fires each time a record is pulled from the database >>> >>> >>> >>> >>> >>> Fred >>> >>> >>> ------------------------------ >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *Omega LiPO >>> *Sent:* Saturday, December 06, 2014 1:38 PM >>> *To:* [email protected] >>> *Subject:* Re: need some ideas from you how to show incidents records >>> over 4 hrin red color. >>> >>> >>> >>> ** >>> >>> Hi Fred, >>> >>> Cool. This is what in my original ideas but I don't know this "on get >>> filter" any quick screen dump about this on Get filter" . Haha, I *only* >>> know to use escalation to make the running-hr growth. Which needs to check >>> the selection-color. >>> >>> Probably this is my first choice of testing on Monday morning. Thank >>> you, Fred. >>> >>> Regards, >>> Omega >>> ------------------------------ >>> >>> *From: *Grooms, Frederick W <[email protected]> >>> *Sent: *6/12/14 1:30 AM >>> *To: *[email protected] >>> *Subject: *Re: need some ideas from you how to show incidents records >>> over 4 hrin red color. >>> >>> ** >>> >>> I was about to say >>> >>> You know … This would be so much easier if you could use Display >>> Only fields from the “source” or underlying form in a table field. >>> >>> >>> >>> I just realized that you can select a Display Only selection field on >>> the source form for the Color attributes of a table field. This should >>> mean all you have to do is to add an “on Get” filter to the source form to >>> set your color selection field. No Escalation needed. >>> >>> >>> >>> Create Display Only fields on your source form to hold running-hr and >>> color selection >>> >>> Create one or more “on Get” filters on the source form to do your >>> calculations >>> >>> >>> >>> NOTE: I would use $SERVERTIMESTAMP$ instead of $TIMESTAMP$ so you get >>> the exact time when the filter fires >>> >>> Fred >>> ------------------------------ >>> >>> *From:* Action Request System discussion list(ARSList) [ >>> mailto:[email protected] <[email protected]>] *On Behalf Of *Charlie >>> Lotridge >>> *Sent:* Friday, December 05, 2014 10:35 AM >>> *To:* [email protected] >>> *Subject:* Re: need some ideas from you how to show incidents records >>> over 4 hr in red color. >>> >>> >>> >>> ** >>> >>> Anyone who's read anything I've written over the past year (that I've >>> been contributing here) knows I'm a big fan of using Remedy views over SQL >>> views. And I've used this mechanism to implement exactly what you're >>> looking for here, but without the table walk logic...much (much much) >>> faster and more efficient since the database is doing all the work. >>> >>> >>> >>> In my case I wanted to implement something that showed a more typical >>> aging ( < 30 days, 30-60 days, 60-90 days, > 90 days) but like you I wanted >>> these differences to show as colored rows in the table. And while your >>> requirement is to show aging measured in hours and mine is in days, the >>> difference is irrelevant to the underlying solution. >>> >>> >>> >>> I'm not going to get into any detail here unless there's some interest >>> that I do (it would take a bit of research & review to put it all >>> together). I will mention, though, that the solution requires that the >>> DB "know" the current time as a Unix epoch timestamp (and *accurately*, >>> especially for your fine grained requirement). Of course all DB's know the >>> current time, but a >>> >>> >>> >>> [The entire original message is not included.] >>> >>> >>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
