When I delete fields from the dictionary any browse procedure window that used the deleted field becomes inaccessible. How can I avoid this or gain access to the window again? Thanks.
go into the window properties […] and manually remove the fields from the list there are probably ERROR links in the window source
for any old field copy any field into that location then open the window normally and delete the column from the table list.
This has been around since version 6? I am using v 12. I hope I am reading this wrong.
I think the handling of missing dct fields changed in C10 and as @KevinErskine mentioned the window formatter now shows an error in the source for the window. Which is relatively easy to fix.
Well, if you delete a field, that is used by a template, you’ve got to expect errors, so my advice is a/. don’t delete fields from the dct or b/. delete them from your apps before you delete them from the dct.
This changed in C7.
And its definitely not a regression but an improvement.
If the code in the window is wrong, the IDE now shows it as wrong. You can see the code, fix it (and remove the error description.)
C6 allowed all sorts of errors, some which caused a compile error, some which caused a runtime error, snd some were just ignored.
Its a lot better that the IDE tells you what is wrong, and shows you where it is so you can fix it.
In C6 to later conversions there are a number of errors in the screen declarations that need fixing.
If you delete fields from the dict, which are on a window, then definitely the IDE should generate an error.
Thats a matter of debate.
C6 shows the error, as highlighted, and then can be handled accordingly.
Deletes occur for a number of reasons, if they didnt then backend databases become junked up.
My position is C6 handled dct field deletes properly in the appgen.
Loading the App threw up a message saying what procedure and field was deleted.
Compiling threw up a syntax error like Bind() errors if the field was missing from a browse list.
Having to edit source to correct the error caused by a missing dct field from a procedure is a regression and begs the question why not just go back to handcoding instead of using the AppGen?
The reason it’s better in C7+ is because the comment, generated by the eror explains what the field used to be. In other words it adds information which can be used to fix the error, not just to remove the control.
Many of the errors detected by the IDE and compiler in C7+ are simply ignored in C6. They are not reported, they just gloss over it. This is becomes apparent when converting apps from C6 to later versions. These errors are now flagged and have to be fixed.
This is an improvement because more-correct code is always better than code that has random nonsense, which could lead to misunderstandings or errors later on. Code should always be correct, at least from a syntax point of view.
Having spent many (many) years working in C6 and earlier, and maybe 15 years working in C8 and later, I have no doubt, from my perspective, that a stricter IDE, and a stricter compiler, leads to better program outcomes.
Those who would prefer to stay in C6 are welcome to do so. But I don’t think C6 is better in any shape or form. It’s hard to list the differences, but the editor in C6 didn’t so much as have color syntaxing or Ctrl-Z. And I find the endless clicks to go down yet-another-dialog very tiresome.
Officially I stopped supporting C6 in 2013. That was some years after moving to C8+ for development work. (All our examples were still made in C6.) Using C6 in that time really drove home to be how bad it had “become”. (I say “become” because I was a big fan of C6 until I switched.)
Yes, the work-flow in C7+ is different. And the muscle memory is different. And all the options are new (and plentiful). But within a couple weeks of real use all that is history, and going back to C6 feels primitive.
Just my opinion - YMMV.
So when I see an error and correct it in the generated code it flows back into the application database?
No. The error here is not in generated code (ie a CLW) file. It’s in the window designer, in text mode.
Its the equivalent of editing code in an embed point.
Thanks Bruce. That clarifies it a lot. It has been almost 20 years since I used Clarion. I started with the first version of Clarion for DOS and used it thru Clarion for Windows until 2008 - V6 I believe.