Opus 10 passes extraneous data to app via context menu?

[rcoleman1943]

OK, I've ended the subject of this thread with a question mark intentionally, but it looks like that's what's happening. Unfortunately(?), it's only happening sometimes.

I have the following context menu entry for All Files:

Normally, I only have the first line which is intended to edit text files with the text editor Kedit. I've added the second and third line for debugging purposes.

Recently I noticed that when attempting to edit files in directory D:\Bat, I started getting an error from Kedit something along the lines of D:\Bat being invalid, locked, or protected. I can't seem to capture one of these (can't produce the error right now). I suspect the error message may be not describing the real problem very well.

(I discovered the problem in directory D:\Bat, but I've seen occur elsewhere also).

After adding the debugging lines and attempting to gather data for this post, I've been able to get only one maybe useful example.

In that case, I had attempted to edit the file D:\Bat\archive_clear.rex.

The data shown came from my first debugging line. In Rexx the Say arg(1) instruction should display the argument passed to the command which appears to be shown on the line following the instruction. Actually, because I have tracing on in my Rexx script the first line following Say arg(1) is a tracing line. The next line is what is output. The beginning D:\Bat\archive_clear.rex should be there, but all the following gibberish shouldn't. I suspect, but can't prove, that this extra stuff is what is confusing Kedit.

I added the line that runs Temp.bat in an attempt to get output in a way that would be familiar to more people, but haven't yet captured anything useful from it.

The appending of extraneous data to the argument is, as far as I can tell, a random event. At the moment, three different applications should receive the argument. It doesn't even appear that the results are consistent within one use of the context menu. One or two instances of the argument may be OK and the other one or two not as far as I can tell.

I only started to notice this recently on 10.0.0.6, but today installed 10.0.0.0 long enough to see that the problem could appear there also. I think I only started seeing this recently, because I haven't been doing the activity where it occurs much. I'm almost sure the cause is not something else that happened recently because I restored a system image from a month ago (Opus 10.0.0.2) and saw at least one instance of the problem while using it.

This problem has the nasty characteristics of possibly being unique to me and almost certainly being intermittent. For now, I'm going to leave my context menu item in its debugging form and see what happens.

[Leo]

I have a similar context menu item which runs TextPad, and which I use all the time. I'd be surprised if there is a bug here, unless it's only triggered by using @sync or {filepath$} instead of {filepath} or some other obscure difference. My menu runs this:

"C:\Program Files (x86)\TextPad 5\TextPad.exe" {filepath}

It'd be worth finding out what the .bat file reports in case it's something particular to Rexx.

[rcoleman1943]

I have another one which doesn't use @sync and which uses {allfilepath$}. Not sure yet if that has the problem. As I said, it seems to unfortunately be intermittent and unpredictable.

I understand the concern with Rexx, but, of course, the real issue is with Kedit and never occurred, I don't think in Opus 9.

[rcoleman1943]

OK, I now have a context menu entry as follows:

Here is cmtest.rex:

/* */ trace ?r Say arg(1)

and cmtest.bat

@echo on echo %1 %2 %3 %4 %5 pause

I just used the context menu entry to edit the file G:\Themes\RRC Default.theme. What happened was that Kedit edited both that file and an empty C:\Windows\System\32+S. This in itself doesn't offer any useful information but look at the results of the accompanying executions of cmtest.rex and cmtest.bat.

Note that due to the current structure of the context menu item using a variable, Kedit, the Rexx file and the Bat file should have all been passed the same argument which should have been "G:\Themes\RRC Default.theme", but seems to have been "G:\Themes\RRC Default.theme"+S.

Where did the +S come from? Based on other instances of the problem, I don't think there is any significance to the specific characters +S. I think they are just the current example of random extraneous data sometimes added to the parameter passed via the context menu.

It's important to emphasize "sometimes". This behavior is unfortunately intermittent. I haven't so far been able to discover any pattern in when it happens and when it doesn't happen.

[Leo]

Try disabling all 3rd party context menu extensions (see the FAQ on crashes when right-clicking files for details; note that you should be able to use the ShellExView tool to disable that type of extension and it'll affect Opus 10 now, unlike Opus 9).

My guess is that something is trashing memory at the end of the filename, and it's possibly a shell extension that has also had the name passed to it. (It's possible that Opus itself has a bug that's causing this, but that seems unlikely as if such a bug was there lots of people would probably see it often enough that we'd have lots of reports or have seen it ourselves.)

[rcoleman1943]

I don't think there is any advantage to using {filepath$} and {allfilepath$} instead of {filepath} and {allfilepath} here.

For the next step, I've changed my context menu entries to use {filepath} and {allfilepath} on the off chance they behave differently. If I continue to see the same problem, I'll probably go back to Opus 9 for a while and see what happens.

Why don't I follow the advice about context menu handlers? Two reasons: 1) It would be difficult to establish whether it's having a desired effect on a problem which isn't reliably repeatable in the first place. 2) Since I think (but may find out for sure) that this problem occurs only in Opus 10, not Opus 9, I find it difficult (not impossible) to believe the problem is elsewhere.

I understand, I really do, the reluctance to believe that a problem seen only by me is an Opus problem and that you can't find and fix a problem that only I have and worse yet only intermittently, but I'm still coming very close to the limit of my tolerance for trouble that occurs in Opus 10 , but not Opus 9.

Of course, if I do go back to Opus 9 and see the same thing, then I'll have to adjust my whole mind set about this.

[rcoleman1943]

On reflection, I suppose I'm not absolutely certain this is an Opus 10 only problem. I don't think I saw it until sometime in the past week or so. This leaves open the possibility that some other cause became present recently, but it's also possible that I just didn't use the relevant context menu entries often enough to encounter the problem in the first few weeks of Opus 10 use.

I may have to reinstall Opus 9 just to satisfy myself that this is or is not a problem unique to Opus 10, but first I'm going to continue to use {filepath} and {allfilepath} (without $) in Opus 10 just in case I should be lucky and the problem doesn't occur when using them.

[rcoleman1943]

I have no idea what caused this problem or whether I will ever see it again, but I haven't seen it since my last post nor have I, as far as I know, done anything to prevent it.