[PD] Number atom box limits overstepped

[William Huston]

Joao,

IIRC, some objects in pd-extended, like hsliders,
would always respect the limits whether dialed-in, or
when coming from an input.

When i finally switched to vanilla, I noticed the same thing,
limits were not respected on the inputs, and a lot of my patches broke.

I don't know whether the "sensible" behavior was ever in the
mainline branch, or only in -extended.

It would be nice if we could request the sensible behavior in a PD patch.
I know it's always hard to change the behavior of an object w/o breaking
compatibility with older patches.

But it would be nice to be able allow a checkbox that says
"enforce limits on inputs" (which is the sensible thing).

BH



On Thu, May 11, 2023 at 3:19 AM João Pais <jmmmpais at gmail.com> wrote:

> Hello list,
>
> after all this time, I just noticed something which I'm not sure if it
> was always like that or it changed without me noticing it: in atom boxes
> one can define the lower/upper limits, which work when dragging with the
> mouse, but don't work when inputting a number or sending a message - the
> numbers go further. Since usually these limits are there to make sure
> that unwanted information doesn't go further, wouldn't it make sense to
> make those limits work on all cases?
>
> For what it's worth, I checked on Max and that's the behaviour there. It
> seems strange to say "here are the limits, but in this and that
> situation they're ignored".
>
> Best,
>
> Joao
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230511/b26af0fd/attachment.htm>