[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] Context-query tid parameter issue
|
Hi Scott,
why don't you simply use double quotes all the time around your property
value? From the service point of view, the property is either a number,
a boolean or a string. This is used for parsing the context query but in
the end the context query comparator function receives a string. So this
is up to the service implementing the comparator to parse the property
value.
- Christophe
On 9/21/2012 5:42 PM, Tepavich, Scott wrote:
When originally adding context query support for breakpoints, we only
tested against Linux. Part of the query allows for the user to enter a
TID or PID for context filtering of the underlying OS attribute. This
worked perfectly due to the nature that Linux supports decimal
formatting of these fields.
Recently we attempted to test this same workflow for another RTOS. This
OS supports hexadecimal TID and PID values, and this form is more
natural for the user in this environment. When these values are placed
in the context-query string and sent to the agent, the
parse_context_query() routine down in the agent returns an error (since
it’s expecting a decimal value).
The interface defined for setting the context query, attempts to allow
the user to compose/edit the string by hand. If we attempt to solve the
problem in the client, we would need to parse the string when the user
has completed entering their text, and convert the hex into decimal.
Either that or return an error to the user stating that hexadecimal is
not a valid form.
The latter is not a solution. The former is problematic when
re-fetching the defined query for the user. The values in the string
would be stored as decimal values, and the client would not have enough
criteria to choose which form to display to the user. A “view as hex |
decimal” option could be inserted, but this can be problematic where
there are multiple numeric fields and each is typically viewed in
different forms.
This could be solved more simply, if we allowed a freeform expression of
numerical values as (at a minimum) decimal or hexadecimal for context
queries. I pose the question if it would be acceptable if I updated the
context query parser to allow for this? I think I already know the
answer, but feel compelled to ask…
Thanks for your time –
Scott
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
