Edit mode vs. Browse mode

[Gregory1701]

I (as well as at least one of my coworkers) think it would be nice if the open source member tab somehow indicated whether you were in Edit mode or Browse mode. RDi does this by showing a pencil vs a spyglass.

The problem we're looking to resolve is this.

• Ctl+Alt+P and open a source member which exists in my development library as well as in production
• I opened a version of a source member that is in our production library (let's say by accident)
• Start making the necessary changes, then go to save the source member, compile, etc.
• But then I discover that I cannot save it. I do get notified with this:
  
  However, maybe I'm the only one, but if I get a bunch of source members open, then get pulled into a teams meeting, then go for a run, come back and start banging out some code changes, it would be nice to have the icon at the top (like in RDi) letting me know that I'm in browse mode.

[sebjulliand]

Hi!
I understand your issue here.

When a member is actually opened in read-only mode, it shows a lock (and doesn't let you type anything in the editor, too):

But that happens if the source member is open in read-only mode (which is something you do willingly).

In your case, the source member has been opened for edition but it's not possible to save it; which is something VSCode doesn't know until you try to actually save it.

One way to address this would be to check beforehand if that member can actually be written to.
@worksofliam, @chrjorgensen : I guess we can run CHKOBJ OBJ(B/A) OBJTYPE(C) MBR(D) AUT(*WRITE) before opening a source member and open in it in read-only mode if the command fails. What do you think?

[worksofliam]

@sebjulliand I think you're on to something for sure! Curious as to where this will be implemented. I am guessing in the QSYS FS provider?

[sebjulliand]

I didn't have a look at it yet but yes, probably something along those lines 😃

[chrjorgensen]

@Gregory1701 My remark about a message when a member is opened for readonly was written 6 months ago, but I still remember my thoughts back then: If the user does not have any indication of the source file or member being readonly (protected), there should be a message if the member is not editable and thus opened for read.

This message would almost never be seen - since the object browser will show the lock icon if the filter is protected or the user does not have *WRITE authority to the file. But the user could have a filter opened and another user locking the source file, by then no lock icon is shown for the first user and he/she would expect to be able to edit.

I agree fully on your arguments and your request for a default option for open for browse. This was my default back then in RDi, before I switched to C4i.

@sebjulliand Your recap looks fine - OK from me.

[sebjulliand]

I hear you guys 😄 I'll do something based on @Gregory1701's suggestion too: add an "Open" submenu to members that will offer to chose between "Edit" and "Browse". Left clicking on a member will still open it, but a new global setting will define if the member is to be opened in read-only mode by default or not. This should help addressing everything raised here.

ctrl+alt+p and ctrl+alt+o behavior will remain unchanged since both already offer to open in browse or edit mode.

[Gregory1701]

@worksofliam tagging you in per your request.