digital state read to test for If or While loop

[mebrauns]

This issue has been tested using the target Micro:bit in Make Code

https://makecode.microbit.org/

Currently, in Blocks, a user cannot add a digital state read to the test for if or while loop. You can find a picture of the attempt to place Digital State Read for If. Here is example code in JavaScript below:

basic.forever(() => {
    if (true) {
        music.beginMelody(music.builtInMelody(Melodies.Dadadadum), MelodyOptions.Once)
    }
})

Using Blocks, it appears a user can add a digital state read to test for if or while loop. So you can find a logic fix that was tried using Digital Read Pin. However, this attempt was not successful on the physical device. You can find the JavaScript below:

basic.forever(() => {
    if (pins.digitalReadPin(DigitalPin.P1) == 0) {
        music.beginMelody(music.builtInMelody(Melodies.Dadadadum), MelodyOptions.Once)
    }
})

It appears that the only way to resolve this logic issue (Digital State Read to test for If or While loop) is with a more complicated implementation using Blocks. You can find the fix below:

control.onEvent(EventBusSource.MICROBIT_ID_IO_P1, EventBusValue.MICROBIT_BUTTON_EVT_UP, () => {
    music.beginMelody(music.builtInMelody(Melodies.Dadadadum), MelodyOptions.Once)
})

Can you implement digital state read to test for If or While loop?

Issue discovered by Richard Albritton

[riknoll]

I think we should remove the check on if/else and while blocks or at least let numbers and strings be dragged in. My only concern is that it might be weird with Scratch blocks, where different types are different shapes.

[RichardA1]

@riknoll, so will the digital read pin return to a string and not an int or bool? If so, that should probably be what changes. The only possible outcomes from a digital read will be 1 or 0 and that should resolve as True or False in the test.

If the currant test looks for an int, making digital read pin return as an int should fix it unless there is a reason digital read pin needs to return another data type.

[riknoll]

@richard1 I'm not suggesting that we change the digital read API, it will still return a number. I'm just suggesting that we change the if/else and while blocks so that you can drag numbers and strings into them without them bouncing out (the current behavior only let's you drag in variables and booleans)

[RichardA1]

Ah, so if we first assigned the digital read pin to a variable, then added that variable to the test, would that work?

Is there a reason why digital read pin it not returning a boolean?

[pelikhan]

Is there a reason why digital read pin it not returning a boolean?

Mostly historical and backward compat reasons.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.