1. David Lacey
  2. PowerBuilder
  3. Sunday, 11 November 2018 10:25 AM UTC

Hi All,

I am hoping that the community can point me in the right direction here to try and track down why a specific window in an application crashes consistently on an attempt to open.

Running under Windows 10 and built with PB2017 R3, Build 1858, the scenario is  

Window opens and performs normally when run from the PB IDE.

Whan running executable from a Windows File folder, the window crashes consistently. I have run with /pbdebug and unfortunately there are no clues in there. The last lines of the pbdebug output are

      Executing instruction at line 5
      Executing instruction at line 6
      Executing instruction at line 7
      stack size changed during a routine call
    End class function +CREATE for class W_MYWINDOW, lib entry W_MYWINDOW

and then nothing else. It appears to have finished the class function and then blown up. 

Now, the strange thing is that if I shell out to dos or create a batch file to run the executable, the window opens and functions correctly, as it does when the Windows compatability troubelshooter is activated. Alas, these are not viable workarounds in our environment.

In an attempt to see if I could trap the runtime error, I added try catch to code code in several events and functions in the window and it's ancestor, but that made no difference.

Any advice, greatly appreciated.

Thanks

Davy

 

 

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Sunday, 11 November 2018 16:10 PM UTC
  2. PowerBuilder
  3. # 1

Hi Dave;

   What you are describing sounds like your running under a different version of the PB runtime than what the IDE is using. Check your System Path.

HTH

Regards ... Chris

Comment
There are no comments made yet.
Brad Mettee Accepted Answer Pending Moderation
  1. Sunday, 11 November 2018 15:38 PM UTC
  2. PowerBuilder
  3. # 2

What you're describing is a DLL conflict of some type. One or more DLLs may be a different version than expected.

Does your app use any external DLLs? If so, check that there are no duplicates on the system, or, if there need to be duplicates, that they're all the same version. If you do need different versions, make sure only the version that applies to this application is in the path, or that none of them are in the path and only in the same directory as the application.

If there are no external DLLs, then one or more of the PB dlls may exist in multiple places on your machine. The same principles apply as above.

To generate a text file with results of a search in your own Documents folder, use this from a cmd prompt:

DIR C:\'filename'.dll /s/a/b > "%UserProfile%\Documents\SearchResults.txt"

Substitute the actual filename (or use wildcards, like PB*) as appropriate. Each line will contain the full path and filename. If you want to get dates/times, remove the /b from the end of the DIR command (format will be like a regular dir command).

Comment
  1. David Lacey
  2. Monday, 12 November 2018 09:34 AM UTC
Many Thanks for the responses, Chris, Brad. Much appreciated.

As well as looking into the path, which I am doing now, would a worthwhile approach be to use the PB2017 run time packager to get the necessary dlls etc and copy these to a new folder along with the .exe and .pbds. If I then ran the exe directly from this new folder would this guarantee that I am picking up the correct dlls etc?
  1. Helpful
  1. Brad Mettee
  2. Monday, 12 November 2018 14:53 PM UTC
See what your search for errant DLLs turns up first.



If want to test, I'd suggest using a VM or another machine without PB installed. If all runs ok with the packaged DLLs, then you can be reasonably certain that there's another set of DLLs causing problems.
  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.