Window-specific global field

[sal88]

Hello all

Is there any way to have a global field which does NOT share its contents across different windows. I.e. populating in one window will not populate it when it is displayed in another.

I'm guessing that it's not as it would sort of defeat the point of a global field. So here is the situation:

We wish to have multiple Case windows open simultaneously. Within each of these windows (which show the same Case layout but different records) we have a global field which is used to define the body of an email that is about to be sent and attached to that Case. We prefer this to be global so as to not lock the record. Therefore, the problem is that if this is populated (but the email is yet to the be sent) then its contents will show in the other windows (which is an entirely different record).

Thanks

[comment]

Why is this field showing in other windows? If I understand your description correctly, it should be showing only when the user is actively composing the mail to be attached to the current Case. This could be in another layout or in a popover or in a tab/slide control panel - or even in a card window or a custom dialog. Once they are done, it can be tucked away.

 

[sal88]

Hi Comment

Please see attached image which I think should explain.

Thanks

[comment]

It explains what you have now. Not why you need to have it this way. Are they ever supposed to compose 2 separate mails, in two separate windows, simultaneously?

[sal88]

I wouldn't say they're supposed to, however there is a lot of multi-tasking and users have become comfortable with dipping in and out of different layouts/windows/records with great rapidity to the extent that it could be argued it is now normal to half finish things before moving on to the next task.

It would appear that I will have to give them a choice between one open Case, and multiple open Cases with an additional click in order to initiate email composition, one Case at a time?

[comment]

If you want to give them the ability to start working on Case #1, then start working on Case #2, then come back to Case #1 and pick up where they left off, you will need to use a variable for each window (or, perhaps preferably, for each Case record).

They can work on a variable directly in a custom dialog. If you want them to work in a global field, you will need to load the field with the contents of the variable when they switch to another window/record. And you will still have the problem with the global showing the same content in both windows. 

Ultimately, globals are not suitable for keeping separate data for separate records.

 

[Dr.Gopala krishnam raju AMBATI]

script using set variable define ur global field with customised variable window names

[OlgerDiekstra]

I have a similar setup where staff can enter notes in separate windows, for the very purpose to be able to start something, take another call, and eventually come back to their older notes. I just use normal textfields rather than globals for this though.

Edited November 1, 2019 by OlgerDiekstra

[sal88]

Would it be possible to record text formatting in the json variable? Currently the global field's contents may be highlighted, bold, coloured etc, but not uniformly, i.e. one word may be bold but the next may be italics, and then we convert that to html when we send the email.

Thanks

[comment]

24 minutes ago, sal88 said:

Would it be possible to record text formatting in the json variable?

What does this refer to? I don't see anyone mentioned a "json variable".

 

Edited November 1, 2019 by comment

[sal88]

27 minutes ago, comment said:

What does this refer to? I don't see anyone mentioned a "json variable".

 

Sorry I should have quoted. I was referring to OlgerDiekstra's post...which they've now edited.

44 minutes ago, OlgerDiekstra said:

I have a similar setup where staff can enter notes in separate windows, for the very purpose to be able to start something, take another call, and eventually come back to their older notes. I just use normal textfields rather than globals for this though.

Is multi-user record locking ever an issue?

Edited November 1, 2019 by sal88

[bcooney]

On 10/31/2019 at 9:07 AM, sal88 said:

We prefer this to be global so as to not lock the record. Therefore, the problem is that if this is populated (but the email is yet to the be sent) then its contents will show in the other windows (which is an entirely different record).

what record would be locked? I would think it's an activity record..not the parent Case. I wouldn't use globals.

[OlgerDiekstra]

20 hours ago, sal88 said:

Sorry I should have quoted. I was referring to OlgerDiekstra's post...which they've now edited.

Is multi-user record locking ever an issue?

I did. I was originally thinking about using a json variable in a global field, as you could store content for multiple windows. But then I thought a bit more about it and concluded that while using a json was possible, it wouldn't be possible to retrieve part of a json for an edit field. You'd get the json data back, which wouldn't work. Trying to make that work would introduce probably considerable complexity.

Record locking isn't an issue as each window layout has the note table as the primary TO. So that record would be locked, but noone else would need to edit that record anyway. And if they do, that's too bad.

[comment]

3 hours ago, OlgerDiekstra said:

while using a json was possible, it wouldn't be possible to retrieve part of a json for an edit field.

I don't understand this part. You can easily add elements to a JSON variable, and you can just as easily retrieve any individual element back. I don't think it's a good approach to take here, because (a) separate variables are easier to implement and (b) storing and esp. retrieving styled text would be a major problem - but it's certainly doable. Where do you see the obstacle?

 

Edited November 2, 2019 by comment

[OlgerDiekstra]

2 hours ago, comment said:

I don't understand this part. You can easily add elements to a JSON variable, and you can just as easily retrieve any individual element back. I don't think it's a good approach to take here, because (a) separate variables are easier to implement and (b) storing and esp. retrieving styled text would be a major problem - but it's certainly doable. Where do you see the obstacle?

 

My initial thought was to use a json var stored in the global field. The json var could hold the content of various windows. But, to edit and display only the content of the window you're in, you'd have to copy the contents for that window out of the json into another global field in order to be able to edit it. And then copy it back again. And when windows are switched, you need to move content again. I figured that's probably too many moving parts. You wouldn't be able to work this with just one global field, you'd need multiple things to make it all work.

I then discarded the idea as not viable and figured I'd remove it all together.

[comment]

Well, I was thinking of one global variable for holding the JSON and one global field for editing a specific element of that JSON.

True, you would need scripts to extract the relevant content out of the JSON variable into the global field for editing, and return the edited content back into the variable. But that's not so difficult. The main problem, as I see it (apart from the styled text issue) is that it will not solve OP's original complaint: the other window will still show the same content. The only thing that will change is that switching to the other window will load a different content - in both windows. As a user, I would find that more jarring than helpful. 

 

Edited November 2, 2019 by comment

[Wim Decorte]

In as much as it applies, one can use the repetition feature of variables to store windows-specific info.  Variable repetitions are numeric but they can be made to work as 'named buckets' by using "Code(<whateer the window name>) so that they can be easy to retrieve by name.  Variable reps do not need to be sequential.

This doesn't solve the problem of wanting to edit content but a round trip to a global field may solve this.

[comment]

6 minutes ago, Wim Decorte said:

one can use the repetition feature of variables to store windows-specific info.

Why yes - that's exactly what I meant when I said:

On 10/31/2019 at 4:43 PM, comment said:

If you want to give them the ability to start working on Case #1, then start working on Case #2, then come back to Case #1 and pick up where they left off, you will need to use a variable for each window (or, perhaps preferably, for each Case record).

 

7 minutes ago, Wim Decorte said:

they can be made to work as 'named buckets' by using "Code(<whateer the window name>)

Provided that the window can be uniquely identified by the first /last/middle 80 characters of its name (the limit of the Code function). That sounds like a lot, but I've seen some people give their windows ridiculously long names.

 

[OlgerDiekstra]

Or would a repeating global field work? That would limit the number of open windows to the max number of repeated fields set, but that way one could edit globalField[1] in one window, and globalField[2] in another without reloading content or overwriting?

In which case you just need to track which window uses which repeated field.

Edited November 3, 2019 by OlgerDiekstra

[comment]

10 minutes ago, OlgerDiekstra said:

but that way one could edit globalField[1] in one window, and globalField[2] in another

You would need to make sure each window shows a different repetition. 

The other thing is that in each window, the user can browse to another record. Which is why I would prefer a variable per record.

[OlgerDiekstra]

 

3 minutes ago, comment said:

You would need to make sure each window shows a different repetition. 

The other thing is that in each window, the user can browse to another record. Which is why I would prefer a variable per record.

True, I suppose you could do that with sliding panels. But then the mechanics of this whole thing starts to get clunky. Unless you can programmatically dictate which repeated field is shown in a window.

[comment]

11 minutes ago, OlgerDiekstra said:

Unless you can programmatically dictate which repeated field is shown in a window.

You could conditionally hide the other repetitions. Still, your description of "this whole thing starts to get clunky" seems apt.

[bcooney]

As an intellectual exercise this has been interesting, but using vars and globals is not the way to do this. Just create an activity record. Why not?

[comment]

42 minutes ago, bcooney said:

Just create an activity record. Why not?

On 10/31/2019 at 3:07 PM, sal88 said:

We prefer this to be global so as to not lock the record.

 

On 11/2/2019 at 1:02 AM, bcooney said:

what record would be locked? I would think it's an activity record..not the parent Case.

If you're on a layout of Case,  then the parent Case would be locked too. Unless you open a card window to the child table first.

 

48 minutes ago, bcooney said:

As an intellectual exercise this has been interesting

It could be practical when you want to have multiple drafts open during a session, without locking any records and without modifying any record until you finalize a draft.

 

[bcooney]

I would be in a card window based on activity. I might trap the commit. 

[sal88]

Thank you for all the responses guys! Having had a little play with JSON (and I had no idea about variable repetitions!), I feel ready to tackle this. I'm going to go for the hidden repetition option. The layout will have 5-10 repetitions of the same field(s), with only the one that matches that window/record being visible, this will be determined by either JSON or native FM variables.

By coincidence, Microsoft Teams has only just released the multi window capability. I'm not sure if the delay was for similar technicalities as my scenario though :D. But it would appear there is (for good or bad) a demand for this kind of multi tasking.
https://www.linkedin.com/feed/update/urn:li:activity:6597210269712207873/

Comment, love your idea of a repetition per record rather than window. This means they can close the window if necessary, and then come back to their draft message. Thank you.

In fact, I may begin with just allowing users to close the Case window, and it storing the message in a JSON variable. If I can't solve the styling issue with a reverse 'GetAsCSS' CF such as this one https://www.briandunning.com/cf/855 I will disable window closure if there is styling present. Once that is working I will move on to multi window.

Thanks again!

[TobiasLiebhartKoschierSE]

After reading all this I am still not sure why you are using global fields in the first place. I don't expect two users composing the exact same email at the same time, and even if, you would have the exact same problems using a global field. So what are you trying to do here? 🤔

[sal88]

On 3/9/2020 at 4:40 PM, TobiasLiebhartKoschierSE said:

After reading all this I am still not sure why you are using global fields in the first place. I don't expect two users composing the exact same email at the same time, and even if, you would have the exact same problems using a global field. So what are you trying to do here? 🤔

As I started to read my very first post that was my first thought also!

In our scenario it is the case that multiple users contribute simultaneously to the same Case/Ticket. If I don't use globals, then a draft message may be seen (and deleted) by another user, and of course the other user won't be able to add their own message until the original has committed theirs. Perhaps I should be using a related draft table instead, the join fields including a global user id set on the parent table. However this just locks the record, which is the other outcome I need to minimise. As Comment points out I could have the related record display in a new window/card, but users have become very comfortable with having the new message field directly below the list of correspondence...I guess it has an instant messaging feel to it.

Or to put it more succinctly:

On 11/3/2019 at 2:03 PM, comment said:

It could be practical when you want to have multiple drafts open during a session, without locking any records and without modifying any record until you finalize a draft.

I am currently still in a single window configuration, however I am using JSON to save/populate the many draft global fields on mode entry/exit. When the solution is exited a dialog pops up if there are still draft fields. It works brilliantly.

However, for saving the email draft field, I am not using JSON, but a global variable, the repetition of which is the Case ID. As I discovered today, FileMaker variables save formatting

If necessary, my next step will be to allow for multiple windows by enabling repetitions on the global fields. I will then hide all but the window-particular repetition. This would be simpler with an option to dynamically specify the repetition number of a field on a layout. I will make the suggestion.

[sal88]

This has been resolved by using the web viewer with some forms and javascript.