Problems after upgrading to version 2.8

Roger_Hall

We are having problems with both insert VNAV detection and with highlighting of lines for programs and records. This started after we installed version 2.8 on our development system. Note that we are still running SRP Editor version 2.6.2 in production, but the problems are occurring on both systems.

The VNAV detection just stopped working. The compilations report no warnings when there should be.

The highlighting issue is that the highlighting of lines does not happen, although the copying itself works. It occurs all the time in production, but only some times in development.

I have attached screen shots of the About windows and General & Style tabs of the Options window for both versions.

Let me know if further information is needed.

Thanks,
Roger Hall
Shoes For Crews, LLC

DonBakke

Roger,

Thank you for taking the time to format your questions and provide us these screen shots. I am guessing that when you say "production", you really mean the production OpenInsight but not a production workstation. That is, you are using the same workstation to access development and production systems. I am making that conclusion because you have the same SRPUtil.ocx version showing in both systems but different SRP Editor versions.

If that is correct, we need to focus on the development system. SRPUtil.ocx v4.0.2 is tied to SRP Editor v2.8. Thus, SRP Editor 2.6.2 is likely to have problems with SRPUtil.ocx v4.0.2. I don't want to muddy the waters by troubleshooting production just yet. Let's resolve development, and then we can upgrade production, hopefully with good results. I'll review this further and get back to you.

Roger_Hall

Don,

Yes, I do mean the production OpenInsight on our network.

Steve got back this morning and installed version 2.8 into that production version. It appears to have fixed the highlighting issue in both versions, so the ocx overlap might have been the cause of that.

However, the VNAV detection is still not working.

DonBakke

Roger,

Are you saying no VNAVs are detected, even the most obvious ones? What about the Editor ++?

Roger_Hall

No, it is the equate VNAVs which are not being detected and Editor++ is catching them.

DonBakke

Roger,

Can you please post a simple example? Obviously it works for us, so I'm guessing your equate(s) have something unique to them.

KevinFournier

The SRP Editor explicitly ignores variables that appear in Inserts due to BLINT's tendency to report false negatives.

KevinFournier

Actually, let me elaborate, because I might have spoken too quickly. The SRP Editor loops through each VNAV returned by BLINT, checking to see if any of them exist in one of the inserts. If so, the VNAV is ignored. It does this because once upon a time, BLINT would mark a variable as a VNAV even though it was initialized in an insert. So, if you have a variable that only exists in the insert, and not in code, then the SRP Editor would likely ignore it. Does that describe your situation? If not, as Don suggested, a code example could be helpful.

Roger_Hall

Kevin, we have the Options box for Ignore VNAVs referenced in inserts unchecked. The insert VNAV checking was working before we upgraded to 2.8, but remember, it stopped working before and you gave us a new SRPUtil.ocx in January to fix it.

Don, I am trying to create a small test program to show it, but it turns out that the VNAV in equate detection does work sometimes. I get the warning in my small program, but I am still not getting it for the larger system program.

Roger_Hall

Kevin, I missed your last post before responding myself. The problem is not with equates not referenced in the code. The problem is with the code using an equate which doesn't exist.

Roger_Hall

I managed to come up with a small test program that I can cause the VNAV detection to work or fail by just commenting or uncommenting one statement:

FUNCTION CREATE_BO_TEST(NONE)

DECLARE FUNCTION OPENER

$INSERT PDP_INCLUDES, LAYOUT_BK_TABLE
$INSERT PDP_INCLUDES, LAYOUT_INVOICE

IF OPENER ( 'BK_ORDER_FILE', FILE_BK_ORDER ) ELSE RETURN

BK_REC = ''

BK_REC = @RECORD
BK_REC = @RECORD
BK_REC = @RECORD

RETURN 1

BK_ORDER$XCH_REF is commented out in the LAYOUT_BK_TABLE insert. If I comment out the IF OPENER ... statement, the VNAV for that equate is detected. If I compile as-is, the VNAV is not detected.

KevinFournier

Is the VNAV supposed to be on FILE_BK_ORDER? If so, this is an intentional feature of the SRP_Editor. The SRP_Editor ignores VNAVS if the variable is used as a parameter to a function. This is because there are many times programmers pass unassigned variables to a function with the expectation that the function will assign it.

This boils down to a judgment call on our part; we favor a less "eager" VNAV detection. Nothing frustrates a programmer more than false positives. (I still get annoyed that DIM arrays always cause VNAV detections.) There is no way to ever know 100% for sure what the programmer intends with any given variable. So, we err on the conservative side.

Thus, your specific case is working as we designed it. However, this thread prompted me to revisit VNAV handling in general, and as a result, the next release will be a little smarter about it. Still, I don't think we would change how this particular case is handled. Your feedback is welcome.

KevinFournier

I just remembered that this is a feature you can turn on/off. In fact, you'll see in your screenshot that you have "Ignore VNAVs in function parameters" checked. Uncheck it and you should get the VNAV again.

Roger_Hall

The VNAV is supposed to be on BK_ORDER$XCH_REF, which seems to be missing from my previous post. Here is the program again, simplified a bit more:

FUNCTION CREATE_BO_TEST(NONE)

DECLARE FUNCTION OPENER

$INSERT PDP_INCLUDES, LAYOUT_BK_TABLE

FILE_BK_ORDER = ''
IF OPENER ( 'BK_ORDER_FILE', FILE_BK_ORDER ) ELSE RETURN

BK_REC = ''

BK_REC = 1234567

RETURN 1

I discovered something else, though, based on your response. If I add the FILE_BK_ORDER = '' statement, the VNAV warning for the missing equate appears. If I comment out the initialization of FILE_BK_ORDER, the VNAV warning disappears.

The System Editor++ always warns about the unassigned variable in the function call. If I uncheck the Ignore VNAVS in function parameters box in the SRP Editor Options, I get that warning there too. But the warning for the equate VNAV does not show.

This led me to realize that the issue is really that the SRP Editor is only reporting one VNAV warning. I came up with a simplified test to demonstrate this:

The insert logic is:

compile insert Logical_Test

equ TRUE$ to 1
*equ FALSE$ to 0
*equ YES$ to 1

The program logic is:

subroutine SPR_EDITOR_TEST ( void )

$Insert LOGICAL_TEST

a = TRUE$
b = FALSE$
c = YES$

Return

I only get the warning about FALSE$, not the one about YES$.

KevinFournier

Thank you so much for taking the time to narrow this down. You are correct. My internal loop was terminating too early. The next release will be more accurate. I'll post a link this evening (I'm at a client's right now) to a prerelease build if that suits you.

Roger_Hall

Kevin,
We can try the prerelease build in our development system.
Thanks.

KevinFournier

This fix requires both a new RDK and new SRPUtil. SRPUtil.ocx 4.0.3 RC1 is here. Make sure to re-register it. SRP Editor RDK 2.8.1 RC1 is here. I look forward to your feedback.

Roger_Hall

I installed both the RDK and OCX into our development system. I then retested both the small test program and my original test case and all the applicable VNAV compilation warnings showed up. We will let you know if we notice any issues. Thanks!

Roger_Hall

The highlighting issue is back, at least in development.

DonBakke

Roger,

Hold off on testing this any further. We think we discovered a problem that slipped past us. Kevin will post a new RC build in a couple of hours.

Also, just a quick note, when you do install the next build (and any other build thereafter), remember that the SRPUtil.ocx will only be registered to the machine you are currently installing/registering the product on. Other users will likely need to have SRPUtil.ocx registered manually on their machine.

Finally, after upgrading to release 2.8 or later (i.e., any release that supports the new themes), we also recommend that each user goes to the Options > Style panel and pick a theme. You can customize the theme as you like, but you'll probably have better results if you start out with a known theme. We wrote the SRP Editor to pick up your existing style settings, but there is a chance that some settings might not play nice with the new theme support.

KevinFournier

My apologies. I grabbed the wrong RDK when creating the downloadable zip file. Please download this zip file and install. That should fix the highlighting issue, which usually occurs when a new SRPUtil (4.0.2 and later) is used with an older SRP Editor (anything prior to 2.8).

Roger_Hall

Kevin, I installed the new RDK into development and the highlighting issue appears to be fixed and the VNAV detection fix is still there. I will let you guys know if anyone here reports any issues. Thanks.

Roger_Hall

Kevin, I haven't heard of any issues with the last RDK. Can we get a production-ready version or was it already that? Thanks.