10.1 Beta

Before I report this as a bug, I want to make sure I'm doing this correctly. I have an inherited window that I want to bring into the local application. The Form Designer tells me it is inherited and it becomes read only. I then use the File>Save As menu. It gives me all of the standard warnings, which I acknowledge. When done, the window still appears to be in the inherited application and not in the local application. Is there a different way I should be doing this?

Don Bakke

SRP Computer Solutions, Inc.

I do this all the time and believe this is intended behaviour. I use the same form name in different application (Inherited) sometimes resulting with quite different functionality. This allows me to have the same menu structure across different applications.

Don, I am assuming you are expecting the local copy to be deleted after copying a form (save as) into a inherited application. This would be a big problem for me if that were the case.

Chris

I do this all the time and believe this is intended behaviour. I use the same form name in different application (Inherited) sometimes resulting with quite different functionality. This allows me to have the same menu structure across different applications.

If you mean that the ability to save an inherited form in the local application with the same name is expected behavior then you are correct. This was always a feature in OI for reasons as you suggested. In our case, we have our base FrameWorks entites in one application layer. If the client's application needs to modify it then we move it into the local application layer. Thus, we can update the base entity without harming the client's customized version.

Don, I am assuming you are expecting the local copy to be deleted after copying a form (save as) into a inherited application. This would be a big problem for me if that were the case.

I'm not following you here. I do not expect anything to be deleted. I'm expecting the entity in the parent application to be copied to the local app with the same name. Then when I go and edit that entity from within the local application I'm given the local entity rather than the inherited entity.

Don Bakke

SRP Computer Solutions, Inc.

Is this a problem with OI10 as I do not see this in OI9.4.6. If I log into the parent account I am editing the parent version just like if I log into the inherited account I am editing the inherited version. Are you including forms and/or stored procedures?

Chris.

I do this all the time and believe this is intended behaviour. I use the same form name in different application (Inherited) sometimes resulting with quite different functionality. This allows me to have the same menu structure across different applications.

If you mean that the ability to save an inherited form in the local application with the same name is expected behavior then you are correct. This was always a feature in OI for reasons as you suggested. In our case, we have our base FrameWorks entites in one application layer. If the client's application needs to modify it then we move it into the local application layer. Thus, we can update the base entity without harming the client's customized version.

Don Bakke

SRP Computer Solutions, Inc.

Yes Don, I can confirm I see this issue in OI10 also. Lock not being released when 'save as' into local app.

Is this a problem with OI10 as I do not see this in OI9.4.6. If I log into the parent account I am editing the parent version just like if I log into the inherited account I am editing the inherited version. Are you including forms and/or stored procedures?

Chris.

Chris - Yes, that's why I identified this post under OpenInsight 64-bit. As I noted, we localize inherited entities all the time with prior versions of OpenInsight. I think we are talking past each other on this issue.

Don Bakke

SRP Computer Solutions, Inc.

Yes Don, I can confirm I see this issue in OI10 also. Lock not being released when 'save as' into local app.

Barry - Thanks. I tested this with stored procedures, messages, and popups and they all work as expected. I'll submit this to the bug tracker.

Don Bakke

SRP Computer Solutions, Inc.

Fixed for the next release.

Carl Pates

View this thread on the Works forum...