Richard Bassett

I have received a bunch of what look like fake email notifications of replies to topics on proivrc. They have exactly the same pattern as the real thing.

In my case they appear to be 'from' proivrcc -at- host186.hostmonster.com

They have a link in them with just an ip address. Judging by Google it's a highly-suspect address.

I sure as hell won't be clicking on those links and if you have received anything similar I recommend you don't..

Not sure many people will be familar with this corner of ProIV but I see from a search that Rob at least was using this a decade or so ago..

I'm planning to put some switchable/escalatable ProIV tracing in place for some batch processes and was just doing some testing to try and figure out what all the various TRACE* environment settings actually do. (For me, this is all Unix/Linux, BTW)

I found a few interesting things and I'll try and post something here later when I'm more sure what's actually useful. But for now I had a question about something that I don't see it doing..

Regardless of what setting I try for the TRACELGC option (or indeed any other options), I can't get any trace indicating all the logic IDs that are executed. All that TRACELGC seems to do is trace a small number of fairly rare operations in logic (specifically SYSF calls and operations on bitflags like ENABLE and DISABLE). When it does that, it shows the logic id or global logic name very nicely but that seems be the only time it shows that information.

Just wanted to confirm this was other people's experience too. Has anyone ever found a straightforward way to trace all the logics that execute?

I have a cunning plan to fall back on but it involves a bunch of extra work (for someone..) so I want to be sure I'm not missing something stupid here.

V6 allegedly includes a 'FOLDER' file type to let you look through the files in a directory via a ProIV function.
I can't find this documented (although proiv.com servers seem to be toast right now so can't say for sure).
Is anyone using this and knows how it is supposed to work or can point me at where it's documented?

T.I.A.

Once, long long ago, ProIV did not have "CRT display update optimization".. this optimization was introduced at some point so that characters on the screen that had in principle been overwritten but which had not actually changed did not have to be sent (repainted) when the screen was 'refreshed'..

Simple concrete example, you start ProIV and run a function called 'FUNCTION', ProIV will send the 8 characters 'FUNCTION' to the actual terminal (emulator), addressed to line 1 column 73, and they will appear in the top right corner of the screen. Now if you link to a function called 'GUMPTION', ProIV will only send the 4 characters 'GUMP' to line 1 column 73 because the 'TION' bit is already on the screen and doesn't need to change.

All good to reduce traffic in the last century when we had slow comms and real green-screen terminals. However, not so good when you're running background jobs on a server and this stuff is being sprayed into a logfile and you'd ideally like to easily see which functions are running..

So.. does anyone know if there is a way to turn this optimization off so that ProIV would paint the screen the simple way it did in version 1.5 or whatever..?

OK, I came across something else that confuses me:

Looking at the 'Properties' docs, I see format text can (apparently anyway) be given both .Inset and .Raised properties (contrast this with the .ShapeProjection property where "RAISED", "INSET" and "NORMAL"are mutually exclusive settings).

Can you really make format text Inset and Raised and if so what does that mean? Or is it just a misdesign and ought to be one property with three settings like .ShapeProjection is?