PFC for pb2019 R3

[mjl38]

Hi,
I'm not aware the PFC have been adapted for pb2019 R3.
I don't think a lot would have to be changed, but I might be wrong.
Can anyone confirm this?
regards
MiguelL

[brucearmstrong2]

There is nothing I'm aware of in R3 that would require any modifications from earlier 2019 versions. I'm using R3 and it's working fine for me.

What is your starting point? 2019 or something earlier.

[mjl38]

Hi Bruce, I'm not really sure if I'm using an adapted version of 2017 or an earlier version of 2019.
Tomorrow, once this horrible tooth pain is over, I'll have a look.

[mjl38]

This is one of the things that should change. I did a change, but cannot seem to find it. See the other discussion I've created.
pfc_n_cst_platform.constructor event:
......
ls_PBVMName = this.of_getPBVMName()
choose case ls_PBVMName
case "pbvm.dll" // pb2019 R3 (and most probably later versions too)
is_ClassName[1] = "FNWND3" // mdi window
is_ClassName[2] = "FNWNS3" // response window
case "pbvm170.dll" // pb2017
is_ClassName[1] = "FNWND3170" // mdi window
is_ClassName[2] = "FNWNS3170" // response window
is_ClassName[3] = "AfxMDIFrame100su" // pb2017 for "dockable MDI"
case "pbvm190.dll" // pb2019 R1 / R2
is_ClassName[1] = "FNWND3190" // mdi window
is_ClassName[2] = "FNWNS3190" // response window
// dockable MDI is now obsolete in pb2019 R2, commented:
// is_ClassName[3] = "AfxMDIFrame100su" // pb2019 for "dockable MDI", same as PB2017
case "pbvm126" // pb 12.6
is_ClassName[1] = "FNWND3126" // mdi window
is_ClassName[2] = "FNWNS3126" // response window
case "pbvm125" // pb 12.5
is_ClassName[1] = "FNWND3125" // mdi window
is_ClassName[2] = "FNWNS3125" // response window
end choose
....
regards

[mjl38]

So, to resume my previous post:
2019 R3 should use:
is_ClassName[1] = "FNWND3" // mdi window
is_ClassName[2] = "FNWNS3" // response window

and previous versions of 2019 should use:
is_ClassName[1] = "FNWND3190" // mdi window
is_ClassName[2] = "FNWNS3190" // response window

[mjl38]

Found the changes in ws_objects.
Shouldn't they be in the ZIP too?
regards

[mjl38]

So that's really funny. I'm asking if the libraries have been adapted for R3 and as a result I did that myself... Getting old.

[bruce-armstrong]

I just created a new release that contains a new ZIP file with PBLs that should contain all the latest changes.

[jojo5791]

Noted with many thanks Miguel. You are my angel. :)

[mjl38]

Lol, you make me blush! Anyway, please use the https://community.appeon.com/index.php/qna/q-a, you'll get a lot of support from several people.
Take care,
MiguelL

[jojo5791]

Hi Miguel, noted. haha.... i have an idea, can i create another new library, named as pfdapsrv, and inherit the n_cst_error from pfeapsrv as pfd_n_cst_error. Then do the rest as you mentioned above. Therefore, in future, any new/overwrite of pfcapsrv and pfeapsrv, would not overwrite my customized changes? Is that correct? Thanks,

[mjl38]

Yes, that's correct, but not really what I'd recommend doing. It adds another inheritance layer to the already bloated pfc classes. It's what a some companies do though.

[jojo5791]

noted. tqvm,

[start2ar]

thanks! Il 08/04/2021 18.42, Bruce Armstrong ha scritto:

I just created a new release that contains a new ZIP file with PBLs that should contain all the latest changes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOG2AWMDC36TZPU4VKU7UNLTHXMIZANCNFSM42QRCCHQ>.

-- <http://www.start2.it> *Tel. 0575984910* *Via F.lli Lumiere, 19* ***@***.*** ***@***.***> *52100 AREZZO (AR)* www.start2.it <http://www.start2.it>