Profound Logic Forums

Hello,

in our development team we sometimes have the problem that 2 programmers change a display file parallel by using the Visual Designer. In the times of SEU this did not happen because SEU locked a sourcefile. Is there a possibility that Visual Designer also locks a file when it is loaded into the designer? If you don't want to create physical locks it would be helpful if visual designer could show a message that someone has loaded the source file.

Dieter

Hi Dieter,

this and of course many more will be handled with an Change Management System like CMOne.
If someone still has checked out an object, it can't be changed from somebody else in general (only Emergency or Multiuser Checkout is also possible) . You will get the Information about who is using this object and on wich Project and Task this object is used.
You also have the integration of UI visual designer and the advantage of setting the correct *LIBL in the designer session. If you have an non converted DSPF and open the visual designer from the eclipse based CMOne plugin, you can also insert a convert theme. just try it :-)

Regards
Andreas

dieter wrote:Hello,

in our development team we sometimes have the problem that 2 programmers change a display file parallel by using the Visual Designer. In the times of SEU this did not happen because SEU locked a sourcefile. Is there a possibility that Visual Designer also locks a file when it is loaded into the designer? If you don't want to create physical locks it would be helpful if visual designer could show a message that someone has loaded the source file.

Dieter

Our development team has the same issue. I know we would be interested in the PUI designer doing this without relying on additional change management software.

Thanks for your feedback.

At this time, the Visual Designer does not require a server job to remain active on IBM i. Its "stateless", so the only time there's an active job to service it is when you click a button that submits control back to the server (like the 'open', 'save' or 'compile' buttons.) Since there's no persistent job running, it cannot hold a lock on a member.

Due to your request, we are discussing this in our development meetings. We could potentially re-write the designer to use a stateful job (much like the RPG programs that drive your rich display files) in order to accomplish this feature... we have not yet decided for certain if we will do this or not.

If there are any other customers (aside from ICS and Ecclesia, who we have already heard from, of course) that feel this would be an important feature, please let us know.

Scott,

i don't want to bring you to make risky changes in the Visual Designer. A few times it happened that two programmers parallel opened the same DSPF source. So some changes were lost. Now we are more sensitized for this problem and we try to prevent this problem by organizational arrangements.

If you are able to solve the problem with passable effort it would by great. But it is not a really significant problem for us in the moment. (Sorry Kevin!)

Dieter

I would not like to see this become the default behavior for the designer. If such an option is incorporated into a future release it should be configurable. Managing source and developer conflicts is what change management tools are for. Relying on source member locks to mange conflicts seems prone to errors.

We sometimes (but not very often) save the DSPF to a local file in order for us to work on the design offline. We also to use the local file to examine/modify the json for the design. Members locks would not be possible in this case.

Dave

Scott Klement wrote:Thanks for your feedback.

At this time, the Visual Designer does not require a server job to remain active on IBM i. Its "stateless", so the only time there's an active job to service it is when you click a button that submits control back to the server (like the 'open', 'save' or 'compile' buttons.) Since there's no persistent job running, it cannot hold a lock on a member.

Due to your request, we are discussing this in our development meetings. We could potentially re-write the designer to use a stateful job (much like the RPG programs that drive your rich display files) in order to accomplish this feature... we have not yet decided for certain if we will do this or not.

If there are any other customers (aside from ICS and Ecclesia, who we have already heard from, of course) that feel this would be an important feature, please let us know.

I would vote for a stateful Visual Designer. It just makes sense to me to lock the object you have opened regardless of my change management control system.

OKay, thanks Sheri. I'll bring this up again with the rest of the developers and see what (if anything) we can do.

I vote to lock the file.

Or checkout a file.