›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Frameworks Version

Opto_WillOpto_Will
in SRP FrameWorks
New user question. How do I find the version of Frameworks installed?
Frameworks Wiki page says the current version is 16.0.18 (as opposed to the product page at 16.0.13)

Basically I am trying to track through the release notes from my version to the current version for some inspiration to an issue I am having. On that subject, are there release notes for .17 and .18?

Comments

  • FrankTomeoFrankTomeo
    Will,

    You can find the version by launching Frameworks and going to File -> About. It will be under the header "SRP Frameworks Information." Alternatively, you can edit the the APP_INFO, ABOUT*FRAMEWORKS record.

    As far as release notes go, the wiki is lagging behind - as the need for development normally outpaces my ability to keep up with documentation. If you are experiencing a specific issue, let me know and I can see if it has been addressed in a specific release, or if you've uncovered something new.
  • Opto_WillOpto_Will
    Frank,

    Thanks for that. I like the APP_INFO tip. Easy enough.

    I will shoot you through an email explaining my issue and you can see if you have any insights....
  • DonBakkeDonBakke
    Will - Ideally we would like you to post the issue on our forum so more eyes can have a look. If that poses a problem please contact me directly so we can work out the best way to address your issue.
  • Opto_WillOpto_Will
    That's not a problem Don :) It was a specific issue SRP has background to but I am happy to generalise it to post.
  • Opto_WillOpto_Will
    I think you are aware that, based on previous conversations, we were looking to merge our own Form Services back with the Frameworks Form Services into a single Enhanced Basic Plus stored procedure. The way we are going to do that is to copy the Frameworks FS over ours and copy back in the few special services we have to create an all-in-one. (our current production standard has our Form Services intercepting and processing our stuff and passing everything else back over to Frameworks). We have already had the discussion on what this means from a maintenance and future integration point of view….

    When I did this merge on our TestBox, it seemingly caused some issues when opening the same window multiple times (This works in our current unmerged production version running Frameworks 6.0.16 [thanks for the tip!] ).
    I admit I am using the Frameworks Form Services version from our performance testing environment (also running Frameworks 6.0.16 but with Frameworks Form Services noting version 6.0.17) as it had all the service Enhanced Basic Plus conversion we were after.

    After double and triple checking I took a step back and went right back to basics. After a little more testing I realised it naturally didn’t work in the Performance test environment either, even with an unmerged Form Services (I should of tested that first!). The only difference to our production environment (on the surface) appears to be the converted Frameworks Form Service. There might be some other background stuff that is different that you will be aware of.

    To summarize my observations:
    Our FS Frameworks Frameworks FS
    V12.02.19 V16.0.16 v16.0.16 Works. Can open same window multiple times (I can provide you my example window if needed)
    V12.02.19 V16.0.16 v16.0.17 Does not work on second window. (SYS 1000. Error loading program message)

    So I guess my question is, is there anything in the Enhanced Basic Plus Frameworks Form Service v.16.0.17 that might stop multiple versions of the same window from opening?
  • DonBakkeDonBakke
    Will - I think the multiple window problem is a red herring. The real issue is the SYS1000 error you are seeing. There should be more information such as the name of the program in the message box as well as the debugger contents. Can you provide that information?
  • Opto_WillOpto_Will
    Don,
    I wish I could :(

  • DonBakkeDonBakke
    Actually, that is more helpful than you might think! That implies that OI is attempting to call a program with no name. In your merged version of the Form_Services do you still have code that handles cases where the GoToService line fails? Do you have any code that calls the Function function?
  • Opto_WillOpto_Will
    Don,

    I had reverted back to our production version so this is not merged and getting that error. We are calling this at the end of our Form Services:

    CallFrameworksFormServices: FuncName = "FORM_SERVICES*FRAMEWORKS" Response = Function( @FuncName(Service, Param1, Param2, Param3, Param4, Param5, Param6, Param7, Param8, Param9, Param10) ) return

    Now that you mention it, We do not have this in that merged version (as it is longer be needed) and we do not get the error, just no 2nd window.
  • DonBakkeDonBakke
    Now that you mention it, We do not have this in that merged version (as it is longer be needed) and we do not get the error, just no 2nd window.


    I think that something is happening with the 2nd instance of a window that is forcing Form_Services to branch to a non-existent service. A side-effect is that you aren't seeing this 2nd window. I am willing to bet, however, that the 2nd window is running but it is simply invisible. You should force the Debugger to open and inspect the list of open forms to confirm.

    My suggestion is to revert back to the merged version but put a debug in the exception branch. Then use this to trace back to the caller and see if this can reveal why the call into Form_Services isn't working as expected.
  • Opto_WillOpto_Will
    Don,

    I think I led you astray with my terminology and short-cutting of descriptions. It was an entire conversation in my head that, in my rush to post yesterday evening, I didn't articulate very well. And from that point on, I thought I had. My bad.

    So when I said "caused some issues when opening the same window multiple times", I meant the Window DOES open, it just doesn't render correctly. The second instance creates the window and displays the fields but there are no tabs, dropdowns, background canvas, etc). All of these are rendered fine on the first instance.

    I did put a debug in the exception area of the merged version like so:
    GoToService else Debug Error_Services('Set', Service : ' is not a valid service request within the Form services module.') end

    It triggers absolutely nothing on the opening. Interestingly, it does fire when closing the first (working) window...an error on QBFCLOSE as a missing service but not on the second(incomplete) window.
    (There is definitely a Form_Services("CloseQBF", MDIFRAME, Window) in the Close Event for the form and just as certainly no such service in the Form_Services!) I am taking this as not the QBFClose OI Event.
    It must have been quietly failing without the debug.

  • DonBakkeDonBakke
    If I'm reading this correctly you have been able to separate two different issues that previously seemed to be one and the same.

    Regarding the display issue for the second window, it seems as if the code that sets up the OLE controls isn't getting called or it is getting called improperly. My first guess is that the form name is being hardcoded rather than the @Window global system variable being used.

    Regarding the call to the (non-existent) CloseQBF service, did this not exist in the custom version of Form_Services?
  • Opto_WillOpto_Will
    As for the CloseQBF service call it is not really an issue (anymore anyway). We possibly never would of noticed if not for debugging this! After consultation, I determined it was meant to be a a call to a stored procedure that effectively does a Send_Event for a "CLEAR" when in QBF mode (it used to be QBFCLOSE according to comments). It should never have been a FORMS_SERVICE! However, not only was it wrong, it was totally superfluous anyway. It was being called in the window CLOSE event so the job was effectively already done!

    I have checked the @Window already but it is always worth a double check!
  • DonBakkeDonBakke
    Just so I'm on the same page as you, we still have one issue left. That is, the 2nd window displays but it still doesn't render correctly. Is this correct?

    Assuming it is correct, did you debug the commuter module at the place where the OLE controls are configured? Also, does this problem happen for any and all windows or just specific ones?
  • Opto_WillOpto_Will
    Yes Don, that is correct. My issue is the 2nd window displays but it still doesn't render correctly.

    I did debug the commuter module. I am about to do it again though (and will do it a 3rd time if needed!)

    I also logged Form_Services with a Logging_Service call to try an identify the difference between the first window and the second window calls with the merged Form_Services. (Spoiler. There was so much activity and they barely looked anything alike in my compare tool!)

    I then logged Form_Services to just compare between 2nd window calls of the working 16.0.16 Framework Form Services and the newer not-working 16.0.17 Framework Form Services. (This involved quite precise timing to try and limit all the other call noise of mouse movement, etc. Then a full reset and change of the FFS to try again)

    I will reiterate for clarity. This is an issue without any merge of Form Services (using our standard production local Form_Services passing through to a newer 16.0.17 Framework Form Services). I know Frank did a fair bit of work in that version to convert it fully to Enhanced Basic+ standard. This is my simple test matrix:
    LOCAL FS FRAMEWORK FS Result V12.02.19 v16.0.16 Works fine (this is our current Production deployment) V12.02.19 v16.0.17 second window opens but does not render correctly. FFS is the only change

    My focus is what behaviour may have changed between v16.0.16 and v16.0.17 of Framework Form Services that means the second window no longer works as it did previously, be it either in the Framework Form Services itself or indeed in our utilisation of it! If there is a difference that requires us to change how we call something then so be it!

    I admittedly haven't tried all the windows but it was certainly evident on all half dozen I did try on so more than enough to prove to be an issue...
  • DonBakkeDonBakke
    Will - I have to confess I'm stumped on this issue. With your permission I'd like to look at this myself. Just let me know which folder on your server I should be looking at.
  • Opto_WillOpto_Will
    You and me both Don!

    Please use E:\OPTO_PT. I just finished proving the issue in there so you should be able to easily replicate.

    You will see a lot of FS versions in there:
    Form_Services*OPTO and Form_Services*FRAMEWORKS are currently both production versions (and work)

    FORM_SERVICES_ORIG = Just a backup copy of your form services to be copied back in as required.
    FORM_SERVICES_WILL = Just a backup copy of our form services to be copied back in as required.

    FORM_SERVICES_EBP = SRP's EBP (What I have been calling 6.0.17) - Taken from E:\OPTO\OPTOPerformance
    FORM_SERVICES_MERGED = A merge of our version with the EBP version (just ignore this )

    Basically my process is this:
    Launch the App and pick any Form and prove 2 Windows work. I used DBW_MATERIAL (New Material) found in Inventory. Its not one I have converted to EBP yet, nor is it Event Managed.
    Replace the FRAMEWORKS Form_Services with the EBP copy (Copy in full text , rename and save/compile)
    Fully log out of OI.
    Re-launch the App and try again. You should see what I mean.
    When done testing, I make sure to copy the original FFS back in (rename and save/compile)

    BTW, If I haven't already said it, I appreciate you taking the time :)
Sign In or Register to comment.