Error after auto check for updates with update

[lscheffler]

📝 Provide detailed reproduction steps (if any)

1. Older Install of Thor
2. Raise Check for updates via RunThor.prg WITH n

❌ Actual result

There is an error on _SCREEN about variable nor found.

Edit: Thor is running.

Edit2: All my subsequent code after RunThor.prg WITH n is stopped. Does not return properly.

[lscheffler]

The error is still there:

See file attached for a DISP MEMO
Memo.txt

[Jimrnelson]

Could you please attach RunThor.PRG? Something is wrong therein.

[lscheffler]

This is the file (relative to Thor.app) Thor/RunThor.prg, filedate looks like the last update, two days ago.
RunThor.zip

[Jimrnelson]

That is exactly as I would expect.

I am going to need some debugging help on this one, as I see that this error is captured by your error handler.

I ask that you look at the code. How could that variable lcFolder not exist? It's defined on the first executable line.

Am stumped on this one.

[lscheffler]

My 0,0002EUR is, that the CLEAR ALL / CLOSE ALL that happens if CFU installs updates clears the variable?
At least CFU came up, and I updated some modules. Should have been clearer in the initial description. Error happens only then.

Debugging this is not so simple, it needs to force an update that open CFU, what is not so easy to reach, next to #227.

The debug set up is, say, tricky. Can't do that without some preparation - one is #225.

[tbleken]

Jim, This file will fail, won’t it? Do m.lcFolder + 'Thor.APP' With 'Run', .T. It’s missing a parenthesis. It should be Do (m.lcFolder + 'Thor.APP') With 'Run', .T. Tore Bleken From: Jimrnelson ***@***.***> Sent: fredag 8. desember 2023 16:52 To: VFPX/Thor ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [VFPX/Thor] Error after auto check for updates with update (Issue #219) That is exactly as I would expect. I am going to need some debugging help on this one, as I see that this error is captured by your error handler. I ask that you look at the code. How could that variable lcFolder not exist? It's defined on the first executable line. Am stumped on this one. — Reply to this email directly, view it on GitHub<#219 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA2UPXFH5EXF6C6SOMM3BTDYIMZQ5AVCNFSM6AAAAAA77HV7GWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBXGQZDAMJQHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[Jimrnelson]

@tbleken

No, I don't think that's a problem. That is the normal published version of RunThor.

Apparently it runs will without the parentheses.

You should have your own version; try it.

OTOH, that would be a reasonable and clarifying change.

[Jimrnelson]

My 0,0002EUR is, that the CLEAR ALL / CLOSE ALL that happens if CFU installs updates clears the variable? At least CFU came up, and I updated some modules. Should have been clearer in the initial description. Error happens only then.

No, the variable is local to RunThor. You should be able to put a stop at the beginning of the code and trace it. This occurs after CLEAR ALL etc is done

Debugging this is not so simple, it needs to force an update that open CFU, what is not so easy to reach, next to #227.

You can force Thor to re-install itself, even if it's current with this:

   `StrToFile(' Force CFU ', _screen.cThorFolder + 'Thorversion.txt', 1)`

Note that this will also re-create RunThor in Thor's folder.

The debug set up is, say, tricky. Can't do that without some preparation - one is #225.

[lscheffler]

@tbleken , @Jimrnelson
Sounds likely, but is not the problem.
On every normal day it runs line 33.
If it is update time, it runs in the first DO .. in line 24, then the EXECSCRIPT( in line 26.
This calls CFU, I install / update some modules. CLEAR ALL / CLOSE ALL is issued during this. (I see the projects closing)
Logically the var is deleted and fails in line 33, as visible on the first message.

[lscheffler]

@Jimrnelson , see the MEMO.TXT output from DISP MEMO in #219 (comment). There is no variable defined at this point. All you see is the errorhandler.

[Jimrnelson]

Yes, logically it is not there, that's the error.

But -- look at the code!

Someplace is a call:

Do RunThor && maybe with parameters?

OOOOOOOOOOOOOOOOOOOOOOOOOOHHHHHHHH!!!!.

Maybe that folder name should be a _screen property after all!

Lutz, can you try adding approach? Instead of a local variable, make that a _screen property?

(It's a little tricker for me to test this as I have a private copy of RunThor -- and we are leaving shortly for the weekend, celebrating number 51)

[Jimrnelson]

Understood. Clearly understood.

The underlying question is how that could happen.

[Jimrnelson]

OK, I don't even need a _Screen property.

There is another, simpler solution.

If all goes well, I will have a fix early next week.

Stay tuned.

[Jimrnelson]

@lscheffler

For now, I think you can try this ... copy the line where lcFolder is assigned and insert it before the call on line 33.

It will be assigned in two places, seemingly redundant, but that should work.

[lscheffler]

I simply turn the update to some days more, so it will wait. No hot fix needed.
For me the whole issue is minor, my problems are more about the closed pjx's - and that the program calling RunThor must fail as well. And that's not one-variable-only.

Only my error handler stops on this error, but this is intended. If this one fails, the next lines will fail anyway.

[lscheffler]

As for the weekend, I celebrate / or not celebrate today first time without Sinéad, it's lonely without her.

[Jimrnelson]

@lscheffler

For me the whole issue is minor, my problems are more about the closed pjx's

Thor has plug-ins to address the problem of closed PJXs.

Using plug-ins is a conscious design choice so that interested users can solve this problem (and related problems, if needed) at their own pace. If they believe their solution is general enough, they can submit their plug-ins to become the default behavior (or part of the default behavior) in Thor.

This allows users the ability to achieve the behavior they want at the pace that works for them, without waiting for the more tedious process of having it released in a Thor update.

If there is to be a change to the default behavior, it may well be due to a combination of contributions from users who have other needs beyond restoring PJXs. (I can only guess at that, but would not be at all surprised by it). It might well be that the final default behavior is only reached in a series of steps rather than all at once. This will happen a lot faster if the development is done using plug-ins.

Finally, since this need is quite hypothetical to me, rather than direct, it helps for interested user(s) to do the implementation and testing.

[lscheffler]

See #96 (comment), discussion belongs there. Here it was just a hint why the problem of this issue is not that urgent to me. :)

[Jimrnelson]

Fixed in Thor 1.46.17 - Released 2023-12-16