Named constants are not working properly

[MatzElectronics]

Named constants should track changes and re-populate menus on the fly. They no longer appear to be:

I believe the fix for this will be similar to the refactor we used with the array blocks - the code for the named constants was derived from the array blocks' code, which is likely why they are now failing in a similar manner.

[MatzElectronics]

This may be fixed in #176...not seeing the issue any longer in that PR...

[zfi]

I agree that this appears to have been corrected.

I am a little concerned that the default "MYVALUE" constant appears in the list when one or more constant blocks have been declared with names other than "MYVALUE". The issue is that the MYVALUE constant does not appear to have a default value, so if it is used in the string variable set size block, the compiler fails with this message:

Compile... Failed!

-------- compiler messages --------
Included libraries: simpletools
single.c:11:11: error: 'MY_MYVALUE' undeclared here (not in a function)
undefined

This needs a resolution.

[MatzElectronics]

Okay, fair enough. It shouldn't be too difficult to remove it from the menu builders when they detect existing named constants.

…

On Mon, Nov 25, 2019, 3:48 PM Jim Ewald ***@***.***> wrote: I agree that this appears to have been corrected. I am a little concerned that the default "MYVALUE" constant appears in the list when one or more constant blocks have been declared with names other than "MYVALUE". The issue is that the MYVALUE constant does not appear to have a default value, so if it is used in the string variable set size block, the compiler fails with this message: Compile... Failed! -------- compiler messages -------- Included libraries: simpletools single.c:11:11: error: 'MY_MYVALUE' undeclared here (not in a function) undefined This needs a resolution. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#175?email_source=notifications&email_token=AEWSVODZS6FBGUAD24AZP5DQVRP3DA5CNFSM4JP6BAF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFEGOKY#issuecomment-558393131>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWSVOA5UA2BKSIOIPHIPALQVRP3DANCNFSM4JP6BAFQ> .

[zfi]

I was just discussing this with @Steph-Parallax and it would actually make sense to just have a default for the MYVALUE appear in the emitted code. It appears to default to 0, so that would allow the default value to appear in the constant name drop downs and still compile.

[MatzElectronics]

Sounds good - definitely the easier approach.

…

On Mon, Nov 25, 2019 at 4:31 PM Jim Ewald ***@***.***> wrote: I was just discussing this with @Steph-Parallax <https://github.com/Steph-Parallax> and it would actually make sense to just have a default for the MYVALUE appear in the emitted code. It appears to default to 0, so that would allow the default value to appear in the constant name drop downs and still compile. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#175?email_source=notifications&email_token=AEWSVOFDA3BUFYTTIHQETRLQVRU5NA5CNFSM4JP6BAF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFEJFJQ#issuecomment-558404262>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWSVOA4BPOR6VGGQSLUPILQVRU5NANCNFSM4JP6BAFQ> .

[MatzElectronics]

Upon further testing, there are still some issues - especially around renaming and deleting named constant define blocks. The solution will be to apply the same principles we used for the array blocks as stated earlier - it will just be a bit of a slog to get through them all.

I would like to de-prioritize it a bit, however (push to a later release, remove from .505 milestone). If you're using named constants, you're probably an advanced enough user to correct it when something doesn't look right. Nothing is "show-stopper" broken...more "mildly annoying" broken in its current state.

[pjewald]

Pulling this out of the 1.4 release. This still needs attention.