This breaks the layout parser:
unview/all view/no-wait [ rich-text 100x100 data [ font 9 i "" /i /font ]] *** Script Error: f has no value *** Where: either *** Near : f *** Stack: view layout fetch-options rtd-layout pop cause-error
I think it may be a fairly recent regression.
Workaround: don't have empty strings :)
Doesn't appear to be a regression, just a bug that's always been there.
parse-url molds the arg, whether it's a string or not.
mold is there because
form doesn't hex-encode URLs, but if it's given a string, can we all agree that it's on the user to ensure they are hex-encoded, or do we drop string support?
decode-url is meant to be higher level, and exists mainly as a name to balance
encode-url, so I don't think we need to expose the refinement there. Do you have a specific use case where that seems better than using
Do you have a specific use case where that seems better than using parse-url directly?
No, actually I could use
It looks correct to remove
string! support from
parse-url, but would be ok to keep it in
decode-url high level function. And instead of
to url! can be used if the argument is a
areaface that has
falsedoes not allow scrolling. I use such a face to display search results and I don't want the user to modify these, but when there are more results than fit in the visible area, I want the user to be able to scroll down. Do we have a bug or a feature here?
areawe should ask @qtxie if it's even possible to scroll a disabled control
textin a scrollable panel instead
view [field "abcd"]
if it's even possible to scroll a disabled control
@hiiamboris There is a ES_READONLY flag. We can give it a try. https://learn.microsoft.com/en-us/windows/win32/controls/em-setreadonly