No, I dont want to present the error code to the user. But if you create the error string in C we cannot translate it into other languages with the Qt translation system. Therefore I would prefer passing an enum or just codes and we host the error strings on the C++ side, where they can be properly translated. The user won'T get to see them.
I am working on an update for the textfield anyhow, this will tie into that nicely
Am Mo., 4. Apr. 2022 um 16:39 Uhr schrieb João Valverde <j@xxxxxx>:
A tool window console that stays hidden by default is probably a
good idea.
Error codes on the other hand are a throw-back to Windows 95. Dial
1-800-SHARK to translate your error code to human readable string.
:-P
On 04/04/22 15:19, Roland Knall wrote:
Sorry, that seemed to be a tippo on the phone.
toolwindow was the term I was looking for.
Actually, for a system that sensitive I would only report
an error code. Those messages need translations and we do not
have that on the c-side of things. Also, usually, error
messages like that get not displayed in the textbox, but
rather as a popup hint/toolwindow, which I was referring to.
But I am very much for making the errors more clear, and
maybe also providing a line position to highlight where the
error began
Am Mo., 4. Apr. 2022 um
16:12 Uhr schrieb João Valverde <j@xxxxxx>:
Not sure what rtoolwindow is.
My idea is that the filter compiler can emit errors,
deprecations and warnings/suggestions, of which only the
first too should be intrusive (displayed in the filter entry
box in red/yellow). To see all messages the user would have
to click a button to open a second level with some sort of
console (which could also find uses to display runtime
errors like integer overflow and division by zero).
I think the system may be improved by
advising the user via a rtoolwindow in the entry dialog,
on how to properly stack the operators. I am currently
looking into that. But at the very least, the release
notes should be updated to contain a note on this.
cheers
Am Mo., 4. Apr. 2022
um 09:59 Uhr schrieb Guy Harris <gharris@xxxxxxxxx>:
On
Apr 3, 2022, at 5:25 PM, João Valverde <j@xxxxxx>
wrote:
> I removed the "parenthesis around &&
within ||" warning/suggestion in [1], then noticed the
precedence of AND and OR is flipped from most
programming languages, then found [2].
>
> The consensus seemed to be in favor of being
consistent with the rest of the world, but in the end
it wasn't done.
>
> Should AND have higher precedence than OR?
Yes, especially if, as I seem to remember Gerald
indicating would be the case, the next release will be
4.0 rather than 3.8. That's the order in C, and
presumably in languages that follow "C" with one or
more characters from the top row of the keyboard :-),
as well as those preceding "C" with the word
"Objective" :-), as well as Java, Perl, Python, Lua
and BPF filters.
We should probably mention this very notably in the
documentation, including the release notes, and
recommend that people use parentheses in all
packet-matching expressions that use both AND and OR.