[Sebastien Tandel <sebastien@xxxxxxxxx>]

Hi,

   If I'm not wrong, the VALS(x), TFS(x) are affected to a const void *
in hf_register_info which in fact are enumerated types. range_string is
not an enumerated type. You then have to decide in proto_tree_add_item,
in fact, a little bit later in fill_label_enumerated_(u)int which is the
type of the structure you have. In the current code of proto.c you can't
decide if it's a range_string or value_string structure at this point.

You then have to implement a mechanism which can decide which type it is
before thinking about a specific treatment in proto.c
You may operate like the following by creating an intermediate structure
which will be used to determine which is the structure we're using  :
(little bit tricky but it's working (I already have a patch for))

*** in value_string.h

typedef struct _rval_val_int {
  guint32 value;
  gchar * strptr;
  const range_string * rstr;
}rval_val_int;

*** in proto.h

#define RVALS(x) (const _value_string*)(x)


*** in your dissector
const range_string rstr[] = {
    { 0, 10, "test" },
    { 0, 0, NULL }
};

const rval_val_int rval_interm[] = {
  { 0, NULL, rstr }
};


After having done this work, you can now change the code of
fill_label_enumerate_(u)int by doing a test on the first string element
of the structure you have if it's NULL => you have a range_string
structure. (you may imagine having more different types of structures,
and then doing a test on string names?)


refinement :
you may define a macro to hide a little bit more the intermediate structure
#define RVAL_INT(rvalstring, int_rvalstring) const rval_val_int
(int_rvalstring_name)[]= { { 0, NULL, rvalstring } };


If you want something cleaner ... one of the solution may be a
intermediate structure which is mandatory with well-defined values to
determine which structure it encapsulates. => need changes then in the
macros VALS, TFS and even in the dissectors using VALS, TFS


Regards,

Sebastien Tandel

Jaap Keuter wrote:
> Hi,
>
> My first impression is that the RS() macro (refer to code sample below)
> needs to be implemented to work with the range_string type. I've got
> really no idea what is involved with that.
>
> Thanx,
> Jaap
>
> On Fri, 12 Jan 2007, Anders Broman wrote:
>
>   
>> Hi,
>> I had a brief look some time ago and it looked
>> To me like it would require new FT_x:s or
>> That the macros VAL and TFS would have to be changed to supply
>> the needed functions. Is there a better way to do it?
>>
>> BR
>> Anders
>>
>> -----Ursprungligt meddelande-----
>> Frï¿œn: wireshark-dev-bounces@xxxxxxxxxxxxx
>> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] Fï¿œr Jaap Keuter
>> Skickat: den 12 januari 2007 15:48
>> Till: Developer support list for Wireshark
>> ï¿œmne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
>>
>> Hi,
>>
>> Yeah, that would be nice, having stuff like this:
>>
>>   static const range_string rs_value[] = {
>>     {  0, 49, "Little" },
>>     { 50, 99, "Some" },
>>     {100,199, "Considerable" },
>>     {200,255, "High" },
>>     {  0,  0, NULL }
>>   };
>>
>>   proto_tree_add_item(tree, hf_proto_value, tvb, offset, 1, FALSE);
>>
>>   static hf_register_info hf[] = {
>>     { &hf_proto_value,
>>       { "Value", "proto.value",
>>         FT_UINT8, BASE_DEC,
>>         RS(rs_value), 0x0,
>>         "How much is it worth", HFILL }}
>>   };
>>
>> + Frame
>> + Ethernet II
>> + IP
>> + TCP
>> + Proto
>>   Value: High (220)
>>
>> That would require weaving in the range string handling along the types
>> where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
>> epan/proto.c comes to mind.
>>
>> Thanx,
>> Jaap
>>
>> On Fri, 12 Jan 2007, Anders Broman wrote:
>>
>>     
>>> Hi,
>>> Does some have an idea on how to implement proto_tree_add_item() with a
>>> range_string?
>>> That would be really useful.
>>> BR
>>> Anders
>>>
>>>
>>>       
>> _______________________________________________
>> Wireshark-dev mailing list
>> Wireshark-dev@xxxxxxxxxxxxx
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>> _______________________________________________
>> Wireshark-dev mailing list
>> Wireshark-dev@xxxxxxxxxxxxx
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>>
>>     
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>