TOPIC:

This is a bit weird. I have a global Mydbserver oLogfile and on the METHOD QueryClose( oEvent ) CLASS IC2StSh I close it with this code:

From time to time I export all AEF's and reimport them in a clean repository but suddenly this line, unchanged for 13 years, gives this compiler error:

Send operator used on non-object type VOID 51562.

What can I do to get rid of this error (except disabling the error, which doesn't seem to give a problem when I quit the program and run this code).

Dick

Dick,

You are most likely changing oLogfile to non-object data type in some other part of your app.

Why not debug and watch the oLogfile object variable and see if its type changes?

Do you have a reproducible example?

Also, I think it is better to test for NULL_OBJECT since a dbServer is an object.

Jamal

Hello Jamal,

Thanks for your suggestions. On debugging, I saw the type remained my dbserver subclass. I think, after all, it was a repository issue, despite having imported everything in a new freshly created one. When I changed my Nil check to what you suggested I got a couple of corruption warnings. Reindexing helped, but with the next change they came back.

Eventually I exported that entity, deleted it, reimported it and via Cavo main menu File/Project settings I enabled error 51562 again. Touched the whole mef, made some changes and now it compiles without issues (as it did the last 13 years) and I can also edit the entity without errors.

Dick

Hi Dick,

ic2 wrote: I think, after all, it was a repository issue, despite having imported everything in a new freshly created one. When I changed my Nil check to what you suggested I got a couple of corruption warnings. Reindexing helped, but with the next change they came back.

Eventually I exported that entity, deleted it, reimported it and via Cavo main menu File/Project settings I enabled error 51562 again. Touched the whole mef, made some changes and now it compiles without issues (as it did the last 13 years) and I can also edit the entity without errors.

That's another shortcoming of VS, it's a pity that it does not offer such huge excitement in understanding, debugging and fixing repo errors, as VO does!

Hello Chris,

Chris wrote: That's another shortcoming of VS, it's a pity that it does not offer such huge excitement in understanding, debugging and fixing repo errors, as VO does!

Haha, I could expect that kind of comment.

However, this is probably the first real repo related issue I had in months or maybe even years. The repo became very stable with the later VO versions. Also altogether it took me 5 minutes to be able to proceed by hiding the error and probably half an hour to solve the issue.

Of course I do see advantages in .Net & X#, otherwise I wouldn't have had two Fox programs for years. I even see an advantage in VS now and then. But the truth is that I spend a considerable amount of my programming time in troubleshooting (errors and VS issues) while in VO I have far fewer troubles and I can proceed again within seconds or minutes.

Dick