• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Change default Directory for DataObjectFactory.LoadDataWindow

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Change default Directory for DataObjectFactory.LoadDataWindow

  1. How-to
0
Votes
Undo
  1. Bernie Rivera
    Bernie Rivera
  2. PowerBuilder
  3. Wednesday, 21 August 2019 21:54 PM UTC

I have noticed that DataObjectFactory.LoadDataWindow uses the App Domain's Base directory to find the pbwconfig file.  This will not work for us since we may have different DataWindow versions with the same name.  We need a way to dynamically set the default directory where DataObjectFactory looks for the pbwconfig file when running LoadDataWindow.

How can go about accomplishing this?

Beside versioning, we have no desire to place any DataWindow information in the App Domain's base directory.

Thanks.

  1. .NET Assembly
  2. .NET DataStore
Local .NET Assemblies from Classic App (update?)
Themes are practically useless for an existing mat...
Responses (2)
Logan Liu @Appeon
Logan Liu @Appeon Accepted Answer Pending Moderation
  1. Friday, 23 August 2019 10:29 AM UTC
  2. PowerBuilder
  3. # 1

Hi Bernie,

Do you mean that you want to switch different versions of DataWindows dynamically?

If yes, please tell us more details about the requirement and solution in your original PB application.

Regards,

Logan

Comment
Load more comments
Logan Liu @Appeon
  1. Logan Liu @Appeon
  2. Monday, 26 August 2019 05:38 AM UTC
There isn’t a suitable solution at the moment. .NET DataStore not only depends on the .srd file, but also depends on its corresponding model class (models with the same DataWindow name may be different). Even if you simply allow the user to reassign the path where .srd is stored, it still doesn't solve the problem very well.

Could you tell more about your original solution in the PB native application. (Are you using the PB library functions?) If you think this business scenario is typical, please report it in the Appeon Standard Support at https://www.appeon.com/standardsupport/.
  1. Helpful
Bernie Rivera
  1. Bernie Rivera
  2. Monday, 26 August 2019 14:38 PM UTC
Our current product is a Web service that receives an SDK request and sends it to a router dll that matches the request to the correct version of our SDK and its installed location, which then instantiates the SDK dll and returns a reply. Our Web service product (ETM) and router dll is wrtten in C#. The SDK is currently a collection of PB 11.5 COM dlls. We are attempting to determine our strategy for moving our SDK to a more current solution. Thanks, we may be putting in a ticket soon for this and also for an error that we cannot seem to resolve.
  1. Helpful
Bernie Rivera
  1. Bernie Rivera
  2. Monday, 26 August 2019 16:15 PM UTC
Oh, by the way, I was noticing your comment about the model class and the srd file relationship. Actually, since our SDK versions each have there own dll, if there were any model class differences they would need the correct srd file to match. That is actually the issue I am dealing with. Each SDK dll would need to be able to load the srd file it was compiled with. That is why I need to have control of the path to keep that relationship intact. Currently, I see no way to control where the datastore finds the srd it needs other than the domain directory, and that directory is shared by all threads. The domain app does not deal with datawindows, only the SDK it instantiates in muti-threaded environment.
  1. Helpful
There are no comments made yet.
Logan Liu @Appeon
Logan Liu @Appeon Accepted Answer Pending Moderation
  1. Monday, 26 August 2019 08:57 AM UTC
  2. PowerBuilder
  3. # 2

Hi Bernie,

How about the following solution (fake code)? 
1. Export .srd and models to different namespaces (e.g.: V1/V2);
2. Assuming there is an available generic class;

3. Then you can create DataStore for different versions using different namespaces, such as:

4. Its code may be more readable. But if you want to writing generic code for both version 1 and version 2, you have to use the interface IDataStore.

Regards,

Logan

Comment
Bernie Rivera
  1. Bernie Rivera
  2. Monday, 26 August 2019 14:39 PM UTC
Thanks, this is interesting. We may have to consider this,but it is not the solution we were looking for, since the datawindows belong to a different install from the domain App. This would require us to address datawindows in a totally different way, but we are still considering our strategy for going forward so, this is helpful, thanks again.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.