Some options in the [scratchblocks] (setting [ v]::sensing) [/scratchblocks] block doesn't work in Snap! 7.
Please explain in more depth.
How does that not explain all the way? I put "Some Options In The Getters And Setters Library Don’t Work" as the title. And I put
That describes everything you need to know.
which options specifically?
EDIT: Is it project notes and project name?
Yes.
And [scratchblocks](setting [user v]::sensing)[/scratchblocks].
User works for me.
In Snap! 7 the JS to get the project notes and name has changed. I fixed this in the project bellow.
https://snap.berkeley.edu/versions/dev/snap.html#present:Username=sir_kitten2&ProjectName=Fixed%20setting%20block
Thanks! I'll incorporate that in the library.
But it still uses plain JS no extension "engine".
That's right; Jens didn't make an extension thingy for this library because he (hates it and therefore) thinks it's reasonable to have to turn on JSF to use it. Maybe I'll talk him into it eventually, but the fact that it's more fragile than most libraries is a realistic concern, as shown by the current thread! :~)
I myself agree with you and Eisenberg on this idea. I might even make an extended version with other (currently) GUI-only things.
Why does he hate it?
he doesn't like complicated JS stuff in snap except for programming snap itself
I have a feeling that's not why.
Well, bearing in mind that I'm not Jens, he doesn't like projects to change settings that aren't published and therefore subject to change. And I'd say he thinks that what you do in the GUI and what you do in a program are often different kinds of things. For example, a clone that you create in the GUI (by right-clicking the sprite's icon in the sprite corral) behaves very differently from a clone that you create with the A NEW CLONE OF block. (The former are "permanent" clones; the latter are "temporary." Just recently he came up with an application in which he wanted to change a clone from temporary to permanent, which up to that point he'd been adamantly against.)
He very much follows the needs of actual projects, rather than the hypothetical needs of a programmer who needs to be able to do everything programmatically. So if you look at the SET [VIDEO CAPTURE] TO (...) block, in Sensing near the bottom, you'll find that there are just five global settings that Jens blesses reading and setting by program. That block is, sort of, Jens's version of the getters and setters library.
When it comes to properties of sprites, Jens thinks there are lots that your program might want to look at (hence the huge menu in the MY block -- Jens also doesn't like hierarchical menus, but that's a different argument), but only nine of them are in the SET [MY >] TO block in Variables.
I, by contrast, think that everything you can set by GUI will sooner or later turn up wanting to be set by program in someone's project, and if there isn't a security problem involved (SET [USERNAME] TO...) then why not allow it? Jens correctly responds that if we do that we're in effect promising never to change how we implement things. I have trouble arguing his side convincingly, but it's not ridiculous; he has good reasons. There are tradeoffs involved.
I really want a username block!
It is kind of a security issue.
How? In Scratch there is a username block. I use the username block for a lot of my projects. Therefor I find it useful.
Notice there is a warning on the project page that uses a username block.