Strange but thats exactly what me and a colleague of mine designed.. I've decided to hide the expansion box of the diary field and build another dialog having 2 fields for the edit and non edit part and 2 buttons OK and Cancel and emulate the diary field functionality using a small button near the actual diary field that brings up this second dialog..
Only functions that users wont be able to do is resize the dialog and have these 2 fields resize automatically, and the option of saving the contents of a diary field to a file or writing from a file to the diary field.. you cant really get it all and yet make it look like the original field.. I could add the edit boxes for those 2 fields but the look and feel will differ distintively.. Rgds Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. ----- Original Message ---- From: Carey Matthew Black <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 8, 2007 11:24:22 AM Subject: Re: RANT: Diary fields in a dialog box.... Joe, I do not think you need to take up more screen space. Keep the history stuff in a hidden field. (This can use the fieldID from the source form) Show the "edit" portion of the diary field. (This should use a value for the dialog UI.) Add a button that opens a dialog window that shows the hidden (read only) part and the current value of the "edit" portion too. When the dialog closes map the value of the edit portion back to the "Edit" field. When you leave the dialog. Clear the "Hidden part" of the diary, and set it with the contents of the "Edit" field. (And I think your "on close" mappings can still work by ID.) In fact I think that design patterns only adds: 1) One "Generic UI for Diary" like window 2) a standard "close" dialog button (could be hidden) to tie workflow to move data around before/after the "apply action" action in Active links. 3) Per diary on the dialog. Orginal diary field (by ID) New "edit" field for the diary. New button for open/close map into Generic UI for Diary One active link for above button. One active link on "close" button to clear/set Original diary field (by ID) before "return of values" And the only thing that I think you will loose is the "hover over" ability to show the "last entry" of the diary in the "edit" portion of the UI. But besides all of that.... Why use a Diary field at all? There are better parent child models that allow "entry level access controls" that would be generally better anyway. (And with Push actions now in the tool, these are very easy to build/maintain.) And if you look at the new v7 ITSM... you might be hard pressed to find a Diary field. :) Yes they are there.. but they are few in number. (193 forms out of 1033 for Incident and Problem have at least one diary field on them. But I have no easy way to count if the users see them or if they are there for just backend logs.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 2/8/07, Joe DeSouza <[EMAIL PROTECTED]> wrote: > ** > > > You hit the nail on the head Axton.. > > > > That's exactly the root of my problems whenever I use diary fields on dialog > boxes.. If an original bit of workflow used matching Id's to set values into > it, the moment a diary field is added and has to be a part of that dialog > (which was my case here) booom... I have to make changes to workflow that > sets fields etc.. > > > > What I'm thinking of doing is almost close to your suggestion but I don't > quite like that idea of creating 2 display only fields, one read only for > setting the history part, the other display only for adding new stuff.. > > > > Workable but not screen smart on the aesthetic point of view when you are > using more real estate to do what could have been done OTB if reading and > writing data to and from both the editable and history part of the worklog > fields was a little smarter.. > > > > As Shyam Attavar, suggested I wonder if this would be useful to have as a > RFE as I really think this would save a lot of us a lot of sweat plus have > our dialog boxes containing diaries a function better without the need for > creating those unnecessary display fields... > > Joe D'Souza > Remedy Developer / Consultant, > BearingPoint, > Virginia. > > > > ----- Original Message ---- > From: Axton <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, February 7, 2007 10:33:10 PM > Subject: Re: RANT: Diary fields in a dialog box.... > > ** Just don't use diary fields. In the case of the packaged apps, create a > display only character field and allow updates to that field. Unfortunate > side effect is that you can not use matching id's in one of 2 actions (on > open/set or save/push). > > Axton ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
