Issue on subsequent CFU

[lscheffler]

📝 Provide detailed reproduction steps (if any)

1. Run CFU
2. Update a module something (Here: FoxBin2Prg without version change, testing Restore projects after CFU #96 )
3. Rerun CFU

✔️ Expected result

CFU should load

❌ Actual result

Error

📷 Debugging Info

Memo dump (a bit of a pain against nesting error, Intellisense was complaining ...)
memo.zip

Update

See #220 as well

[Jimrnelson]

Unfortunately, the DO nesting issue is familiar. This occurred before with the attempt at restoring open projects. I was unable at that time to determine the cause which is why I disabled restoring them (many months ago).

It would be helpful if you repeated and showed the part of the call stack more near the beginning so that it would be possible to see who started that endless stack of tmp executables.

[Jimrnelson]

And I could not replicate this error on my end.

[lscheffler]

It looks like it is endlessly trying to call the CFU form. I do not know why the locals are missing in the dump. If you need something from lower stack, I can produce, the debugger is still active

[lscheffler]

And I could not replicate this error on my end.

It might need to install Thor first. It's subsequent to a CFU run that updates Thor. What nobody sane would do, but I'm checking the issues fixed.

Site note: I changed value of the new option for "Never update" before the problem occurs on the first run.

Update: The picture above is from the second time I run into it. And this time, there is only one instance of VFP active.

[Jimrnelson]

It might need to install Thor first.

Yes, I would certainly expect so.

[Jimrnelson]

It looks like it is endlessly trying to call the CFU form.

Actually, I think it's endlessly trying to find the settings file where the position and size of the CFU is to be found.

But am lost why that could be an infinite loop.

[lscheffler]

5th call of EXECSCRIPT

The parameters lxP* are after call 5 the App only.

The only on thing I know that can creates such odd behaviour is VFP internal cache. That is, one runs an app or vcx or the like.
And then one alters something that VFP is not tracing, and tries the same file again. VFP thinks it knows something about that, tries to access it and fails, because the world has changed.

[Jimrnelson]

So, same question as in the other issue at hand:

If you are testing this as part of moving from an earlier version to 1.47, I have no guarantees.

The large batch of changes in 1.47 all go together and work if you start Thor with 1.47, but not as part of a process where you were updating to 1.47.

[lscheffler]

FYI
Sadly, this is still there with 1.4.7.01

[lscheffler]

The vanilla install / the run via vanilla 1.47 does not have the problem.

[lscheffler]

I do not really understand what should happen. What I see is
_Screen.cThorDispatcher and _Screen.cThorDispatcherClasses are equal. Each takes the first parameter lcPRGName (value "Class= ThorFormSettings"), and does some compares. This runs around line 27

Case Atc([Class=], lcPrgName) = 1
Return ExecScript(_Screen.cThorDispatcherClasses, lcPRGName, lcThorAPP, Pcount(), lxP1, lxP2, lxP3, lxP4, lxP5)

into eternity.

• If I start VFP, the properties are different.
• I run CFU, and close CFU, it removes cThorDispatcherClasses
  
  And the next line "ADDPROPERTY" sets the properties equal. Or not. Or what?? I rerun this for a while, and finally cThorDispatcherClasseswas magically changing without stopping at breakpoint. It needs a lot of time, but finally - I found it changes as soon as I click on _SCREEN. See the video attached. The very last is, a click on the yellow _SCREEN - and the property changes. Any idea?

2024-01-06 17-21-16.zip

[lscheffler]

Update:
There was a lot of sometimes in this. I dived a bit deeper, by clicking some elements of the VFP IDE:

• A click in Command window changes nothing
• A click on a pjx changes nothing
• A click on properties window changes nothing
• A switch from properties to pjx or vice versa changes the property
• Directly changing from Debugger to Menu and recalling CFU changes nothing
• Clicking _SCREEN changes the property

So it will happen only under special circumstances.

[lscheffler]

Update II

• I run this against the vanilla 1.47 updated to 1.47.01 Thor, it does the very same.
• I run this against the vanilla 1.47.01 Thor, it does the very same.
  1. unpack 1.47.01 installation
  2. start VFP
  3. start the Thor.app
  4. finish the whole install, including config
  5. rerun CFU
  6. close CFU
  7. click _SCREEN

[lscheffler]

Update III

It will only raise, if one or more non empty projects are open.

Note, CFU installs or updates nothing.

[Jimrnelson]

There's a lot to unpack here.

---

First of all, the two Thor properties _Screen.cThorDispatcher and _Screen.cThorDispatcherClasses are only assigned when you run THOR.APP.

From your comments, it appears that _Screen.cThorDispatcherClasses is being assigned the value from _Screen.cThorDispatcher. This does not occur anywhere in Thor.

You wrote:

• If I start VFP, the properties are different.
• I run CFU, and close CFU, it removes cThorDispatcherClasses

That's true, but the next line assigns it to its correct value (don't be distracted by the variable name)

When you're done with CFU, before clicking on _Screen, the two properties are correctly assigned, correct?

---

You notes two instances where the property changes:

• A switch from properties to pjx or vice versa changes the property
• Clicking _SCREEN changes the property

There is nothing in Thor that is acting when you change from the properties window to/from a pjx, or when you clock on _Screen.

In fact, I have no idea how it is possible for that to happen. Clicking on different system elements can cause a _screen property to change? I would not have thought that possible. Some sort of event binding? Whatever it is, Thor is not involved.

That is, Thor's properties are involved, but no code from Thor is causing that. Something somehow related to the three system elements you identifies (pjx, property window, _Screen).

---

In Update III you mention that the issue only occurs when you have one more non-empty projects open. That's very curious, for sure, but there's nothing in Thor that knows or cares about open projects.

[lscheffler]

Hi Jim,

The time I used to gather it was not short. So, yes there is a lot off stuff in it.

To your message

When you're done with CFU, before clicking on _Screen, the two properties are correctly assigned, correct?

Exactly. You can watch it on the video provided.

In Update III you mention that the issue only occurs when you have one more non-empty projects open. That's very curious, for sure, but there's nothing in Thor that knows or cares about open projects.

But Thor cares - it stores / restores on update Thor and CFU. This is not nothing.

... I would not have thought that possible. Some sort of event binding? Whatever it is, Thor is not involved. ...

Thor must be involved the one or the other way, My code does nothing aside starting Thor, and others (you?) managed to run into the nesting problem as well.

... In fact, I have no idea how it is possible for that to happen. Clicking on different system elements can cause a _screen property to change?

It is like magic, I agree. But then.
There is one piece of code that run, unknown to most, hidden from us, outside the eventbinding and any event we can trace. It's (system) menu, and in special the skip code. It changes with the focus, it traces memory. I have no idea what all causes the menu to change, but we all know it's enough to access a work area with an open cursor - no matter how - and the sysmenu will change. It changes by changing focus from command window to a project. Other way is, bind a skip to a variable, run the menu an release the var. The menu starts to complain.

More analysis

And there is Thor code running clicking the _SCREEN. I attach an eventlog, starting after CFU is ended, a click to _SCREEN and ending. It's all events, so a lot of MouseMove. But you see the _SCREEN events - and the Thor event.
We agree the paint changes nothing on purpose, but it is running.

Coverage logging shows no code running while the property changes. Anyway, I never saw the skip code in a coverage log.

A wild guess

Since nothing seems assigning the odd value to the property. I have a wild guess. The properties _Screen.cThorDispatcher and _Screen.cThorDispatcherClasses are very similar named. If there is an oddity in the VFP engine that somewhere resolves the names the wrong way and shortcuts, it could access the wrong value.

Possible ways to solve

• try a different naming, those endless names with a little change to the end are hard anyway. I understand what you like to achieve, I do similar, but possibly you might have done to much. I have no idea how the var names are stored internally, but some odd code somewhere out of the days of yore might create a problem, probably with just this name(s). You might remember the days of BASIC where you could name a variable as long as you liked, but only the first 4 chars where significant?
• kludge, without solving the real problem: try to load the code when you need it, instead of storing to the property

---

Off topic

Please have a look at this Debug_Out.log. This is starting CFU, until CFU is visible, and there is an output about an error I have no idea about.

[lscheffler]

Update:
It happens only after CFU. After Configure there is nothing.

[lscheffler]

Update II
Naturally Configure resets the property, so CFU will run again. A CFU after Configure will raise the problem too.

[Jimrnelson]

A wild guess

Since nothing seems assigning the odd value to the property. I have a wild guess. The properties _Screen.cThorDispatcher and _Screen.cThorDispatcherClasses are very similar named. If there is an oddity in the VFP engine that somewhere resolves the names the wrong way and shortcuts, it could access the wrong value.

So far, this is the only suggestion, isn't it? And, I agree, a pretty wild guess.

Can't hurt to try, so I'll give it a go, but this will take more time to test.

[lscheffler]

Sure. I have a way to run without to much fuzz using Configuration and aside testing for solved issues I'm not calling CFU day by day.

If you tell me how you resolved the URL issue and the URL to your fork, I can run a test against as soon as you pushed to your fork.

[Jimrnelson]

If you tell me how you resolved the URL issue and the URL to your fork ...

I do not understand this reference to "resolved the URL issue".

And, as of this moment, I have done nothing with this and because of work issues do not know how soon I can address,

[lscheffler]

If you tell me how you resolved the URL issue and the URL to your fork ...

I do not understand this reference to "resolved the URL issue".

This is, where is the centralized URL for #225 is working? You followed my example or how is this working? Is there a documentation how to use?

And, as of this moment, I have done nothing with this and because of work issues do not know how soon I can address,

This is, since you might have a problem reproducing the error and I not, it might be a good idea to test on my computer. As soon as you think it's ready.
Obviously you are pulling this repo from a fork. I can simply update Thor from this fork on my computer but for this I need to know what you have done on #225 and the fork's URL.

[Jimrnelson]

Item #225 was consolidated into #243 as issues that will be considered together at some later date.

Nothing has been done on centralizing URLs.

I do not expect to be visiting #243 at any time in the near future.

[lscheffler]

Item #225 was consolidated into #243 as issues that will be considered together at some later date.

Nothing has been done on centralizing URLs.

I do not expect to be visiting #243 at any time in the near future.

Beg your pardon, I misread one of the many emails. So I can not help fixing / testing. :(

[Jimrnelson]

Attempted correction in Thor 1.47.02 - Released 2024-01-13 #253.

Two properties created by Thor in _screen have been renamed. A shot in the dark to fix this problem. It seems unlikely to be the solution but no other alternative has been found.

[lscheffler]

Now it runs. Thank you.