• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • 4 Different application objects for same code base

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

Resolved 4 Different application objects for same code base

  1. How-to
0
Votes
Undo
  1. Daniel Mullings
    Daniel Mullings
  2. PowerBuilder
  3. Monday, 18 May 2020 16:31 PM UTC

Good day PB Gurus,

I have an old pfc application, currently migrated to PB2017 R3 and PB2019 R2 Build 2328.  All the code is the same except for the application object, but I have it split up in 4 different folder structures, dev, test, stage, prod. All the app objects are in one pbl, as AppD, AppT, AppS, AppP and propagated to all four folders.  I have a separate target that corresponds to each app object.  There are also 4 different project objects which when built, creates an AppD.exe, AppT.exe, AppS.exe, AppP.exe.  This works fine except that merging changes has become a pain. 

I have combined all of this into one folder with the 4 targets delineating the 4 apps.  Just like they were before except the folder structure is one, instead of 4. The app runs fine in the IDE whenever I run it from each separate target.  The problem lies with the built exe.  It works fine for the first one built, for example, AppD.exe, but when I build AppT.exe, it builds fine.  But copying it to the application folder and running it there, it fails to run with a null object reference.

The app is built with 24 separate pbds and an exe.

Is there something special I need to do with the app object and or the project object?  Put them in a separate pbl? Or is this something that can't be done?

Thanks for any help you can provide.

How to change location of TFS source control serve...
Does Appeon do Progressive Web Apps (PWAs) or Some...
Responses (3)
Phil Wallingford
Phil Wallingford Accepted Answer Pending Moderation
  1. Thursday, 4 June 2020 21:47 PM UTC
  2. PowerBuilder
  3. # 1

Are you trying to share PBDs among the applications?  As Michael implies this is notoriously difficult using the PFC framework.

As a test try doing a full build for a number of the applications, including creating distinct PBDs.  Run them and see of the problem persists.

Regards,

 

Phil

Comment
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Wednesday, 20 May 2020 19:06 PM UTC
  2. PowerBuilder
  3. # 2

Are there *ANY* differences between the application objects other than name?
Meaning: Different library list order; different global variables order; different set of global variables; different set of events + functions on app object itself?

Any of these potentially renders the PBD files unusable for any app object than the target that compiled and built the PBD files.

Make sure all your target-to-EXE PB projects have Full Build - to be sure all compiled code is "inter-consistent"

HTH
/Michael

Comment
Daniel Mullings
  1. Daniel Mullings
  2. Monday, 8 June 2020 19:13 PM UTC
Hi Michael,

Not sure how I missed your comment....

I'll double check to see if there are any differences, should only be the app object name.

Also, we perform a full build every time.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 18 May 2020 21:05 PM UTC
  2. PowerBuilder
  3. # 3

Hi Dan;

   Wow, your the first person I've heard of doing this. Normally, we only see one App object & one EXE name to throughout on apply release.

   Can you explain why your doing it this way, advantages / goals?

Regards.... Chris

Comment
Load more comments
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 19 May 2020 19:15 PM UTC
Interesting.

Suggestion: I would place each App Object and its associated Project object pair in their own PBL. Then tie these together individually via a corresponding Target (per pair). Then add all the regular PBL's to the librayr list for each target. That should then produce one unique App object and EXE pair per Target. Thus, the compiles and EXE's should be clear to the compiler and run-time. HTH
  1. Helpful
Daniel Mullings
  1. Daniel Mullings
  2. Wednesday, 3 June 2020 15:19 PM UTC
Exactly my thought! So I had tried that and it still did not work. :-(

I failed to mention that the app is run out of 4 different folders as well. Program Files (x86)\app\Dev, Program Files (x86)\app\Test, etc. That was apparently the main reason for this approach.

So I added a new app object and set it up to run from Program Files (x86)\app, and added a login to pick the environment to run in. Subfolders underneath this have the Program Files (x86)\app\logs\Dev, Program Files (x86)\app\logs\Test, etc instead of Program Files (x86)\app\Dev\logs, Program Files (x86)\app\Test\logs. The only issue with this approach is themes. If the user selects different themes for each environment, I won't know which one to pick (cause it's set in the preferences in the registry for that environment). The user is presented with a window to select their environment after the ApplyThemes command, thus I have to pick the last used theme. Unless someone can think of a better way?
  1. Helpful
Andrew Barnes
  1. Andrew Barnes
  2. Thursday, 4 June 2020 17:46 PM UTC
We also do almost exactly that. We use PB to create in-house desktop applications. Each app has a production and a beta testing application object that resides in the app's main PBL. For us the reason is that we use a database to store application configuration and user information and use the AppName property as a lookup key into the application/user configuration database table structure.



The main difference with our implementation compared to Daniel's is that we keep the EXE names the same and deploy prod and beta to different folders. Like Daniel's situation, we have been doing this for over twenty years, although in our case, we do not have any problems. Currently we are on PB2017R3, although I had played about with 2019 and experienced no issues either.



The only issues we have ever had would be the ones Michael mentioned being adding a global variable to one app object and forgetting to add it to the other, although that generates a compile error vs. a runtime error. For the runtime error, I guess I would focus my efforts on the different build objects and look for differences. We do our builds using OrcaScript, so it is pretty easy to make sure that the app versions, beta and production, all get built identically.

  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.