[2.0.x] Fix overridden Malyan LCD functions

[xC0000005]

Benefits

When my malyanlcd code was rebuilt, some #ifdef blocks were combined. The result is that the no lcd #else branch is active when MALYANLCD is defined. The null implementations are chosen by the linker and the result is the LCD doesn't work. Putting the function definitions back in their own #else fixes the problem. An "lcd" class might make some of this simpler, but since most of them use the ultralcd class, it would be overkill at the moment.

Related Issues

[thinkyhead]

It looks like this needs a rebase, since it was submitted from an old branch. I will go ahead and attempt it.

[thinkyhead]

Hmm, this has some redundancy, and I'm not sure what it changes. When MALYAN_LCD is enabled, ULTRA_LCD is not enabled. I'll add a new commit to illustrate the result without repeating the null function definitions to make it clearer. Meanwhile, what compile errors were you getting?

[xC0000005]

It isn’t a compile error. Here’s what happens: Without this change, and MALYAN_LCD defined, the first #if block takes effect. That’s great. It declares a couple of functions. The next #if block for UltraLCD is paired with an else that is for NOLCD. You can see in that block it has a number of null function definitions. Now, when the linker goes to put the binary together, it has multiples, ones from the header and ones from malyanlcd.obj. The header ones “win” and the result is not a compile error, but the LCD doesn’t function. Does that make more sense?

…

On Apr 23, 2018, at 2:34 PM, Scott Lahteine ***@***.***> wrote: Hmm, this has some redundancy, and I'm not sure what it changes. When MALYAN_LCD is enabled, ULTRA_LCD is not enabled. I'll add a new commit to illustrate the result without repeating the null function definitions to make it clearer. Meanwhile, what compile errors were you getting? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10498 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcUWTS2uUuN0ZIAU6EpljzalSZraRks5trkjMgaJpZM4TgF9G>.

[thinkyhead]

Yes, now I can see that from your change. I've added a commit that deals with that in a less redundant manner.

[thinkyhead]

It looks like we could also implement the functions that set the status line for the Malyan LCD. Currently only calls to lcd_setalertstatusPGM will do so. Would it be useful for the status line to act the same way on this display as others?

[xC0000005]

At the time I was implementing this, I didn’t understand enough about how the functions differed - I’ll be happy to make an update for this. The Malyan UI is really only capable of showing an error status in terms of lines, so yes, if the status is an error, we should display it.

…

On Apr 23, 2018, at 2:46 PM, Scott Lahteine ***@***.***> wrote: It looks like we could also implement the functions that set the status line for the Malyan LCD. Currently only calls to lcd_setalertstatusPGM will do so. Would it be useful for the status line to act the same way on this display as others? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10498 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcQED2OU3JEtqtZ9-YVd-uU6l7TBLks5trku6gaJpZM4TgF9G>.

[thinkyhead]

Ah, good to know. In that case the other message-setters are ok to leave out. Thanks for the patch!