Why are you manually setting the table count for ARCUS to 1?

You don't need to do anything special for subclass views/tables there. When activating your app, you just treat ARCUS the same as you would any other PZXXXX view. The internals of ARCUS will know what to do. It won't try to create the ARCUS table again. It will just create the PZCUST table. So assuming you have everything else set up correctly, just the standard code should work:

Hello, 

Thanks for your reply.

I was using standard code only but due that issue I tried those custom changes. both way I am getting same result as issue with failing to execute below functions.

1. identifyViewTableCount

2. identifyViewTables

It looks like your activation is right - in that it's using the AR0024 rotoid, not PZ0103. So, the ViewTables line in RVSPY looks correct, and AR0024 is correctly pointing to PZCUST, but the .Load line looks wrong as PZ0103 should point to ARCUS, but it's pointing to PZCUST. So it looks like the problem is somewhere else. I'd assumed the add-in was working as you normally leave the activation code until the end, but I guess you don't have to. Are you sure PZCUST is working correctly? Have you tried creating it in View Tester? If not, some things to check:

Do you have a ROTOARPZ.TXT roto event file with the following line in it?:

PZ0103   VIEW   PZCUST.DLL   SUBCLASSES   AR0024   ; Customers

and is it being compiled into ROTOARPZ.DAT?

In pzcust1.c is the subCmpName correct? It should be the PZCUST rotoid - not the ARCUS rotoid. It should look like this:

extern CHAR subCmpName [SIZEOF_ROTOIDSTR + 1] = PZCUST_ROTOID;

Do you have an Add-in section in your pz.ini file like this?:

[Add-in]
Subclasses=AR

I have done all these configuration as per TU module development. I have checked each and every configuration as per above which is right in place. 

Thanks.

Are you sure the view is working though? What happens if you try to create it in View Tester?

It is created perfectly in view tester when in click on Load and create in view tester. I can able to see that table in database as well once created by view tester.

I reproduced your problem exactly.

The problem is that the subCmpName in pzcust1.c is being set to AR0024 and not PZ0103.

As it says in the comments: "// Because of the way chaining works, this is your own roto ID!"

If the line in pzcust1.c looks like this:

extern CHAR subCmpName [SIZEOF_ROTOIDSTR + 1] = PZCUST_ROTOID;

then PZCUST_ROTOID is wrong.

If it looks something like this:

extern CHAR subCmpName [SIZEOF_ROTOIDSTR + 1] = "AR0024";

then change it to:

extern CHAR subCmpName [SIZEOF_ROTOIDSTR + 1] = PZCUST_ROTOID;

it is already defined as per below in PZCUST1.c  

extern CHAR subCmpName [SIZEOF_ROTOIDSTR + 1] = PZCUST_ROTOID;

about the ROTOID for PZCUST it is already defined as below in PZCUST.h

#define  PZCUST_ROTOID          "PZ0103"

Sorry, my bad. It looked like I had reproduced your problem, but on closer inspection, it's not exactly the same as you were getting.

This is what I got. It looks the same, but yours was looping on the PZ rotoid, whereas mine was looping on the AR rotoid.

I tried lots of things, but couldn't reproduce your problem exactly. The only way I could get it to loop on the AR rotoid is to have the wrong rotoid for ARNAT_CMP and delete the ROTOARDX.DAT file, but it's still not exactly the same as yours as the rotoid for your ARCUS_CMP is correct.

Deleting my ROTOARDX.DAT file does cause the looping though. 

Can you confirm that you have a ROTOARPZ.DAT file in your program directory?

Eg: C:\Sage\Sage300\PZ70A\ROTOARPZ.DAT

Also, what version of the SDK are you using? I'm currently working on an older version of the SDK, so unlikely, but a small chance that you have found a new bug in the SDK. 

Other than that, I'm out of ideas. If you want to send me your code I can have a look at it here. No charge, I'm just curious as to what it is now. You would have to send me all the code necessary to reproduce the problem here though - not just snippets. email: [email protected] Or you can always try DPP support.

Hello Jonh, 

Thanks for your reply, I am using the latest version of Sage 300 2023 version. I don't think there is an issue with roto please find below rotoedit for ROTOARPZ.DAT. This issue is with all subclass views like ARIBH, and OEORDH. while creating a subclass view with init view system it goes in looping and then crashes the sage 300.  

I have raised the concern with DPP Support waiting for a reply from them. 

you can use the same version and create a project with TU tutorials then I think you can reproduce the issue. 

Unfortunately I can't test 2023 right at the moment. If it is a problem with that version, you should be able to re-instantiate the views in an earlier version of the SDK. Eg: just recreate them in the 2022 SDK. As far as I know, 2022 views are compatible with Sage300 2023.