empty tag

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

empty tag

Alvin Wang

HI

If I set a tag as below:
message.set(new Text(text));
and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?

Thanks
Alvin ********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: empty tag

Oren Miller
We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.
 
In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.
 
--oren
----- Original Message -----
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag


HI

If I set a tag as below:
message.set(new Text(text));
and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?

Thanks
Alvin ********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: empty tag

Alvin Wang
In reply to this post by Alvin Wang

Oren, I can understand where you are coming from. It makes total sense if QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks
Alvin




"Oren Miller" <[hidden email]>

07/05/2005 10:00 AM

       
        To:        <[hidden email]>, <[hidden email]>, "Alvin Wang" <[hidden email]>
        cc:        
        bcc:        
        Subject:        Re: empty tag



We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.
 
In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.
 
--oren
----- Original Message -----
From: Alvin Wang
To: [hidden email] ; [hidden email]
Cc: Oren Miller
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag


HI


If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************

Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Oren Miller
My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.
 
--oren
----- Original Message -----
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks
Alvin




"Oren Miller" <[hidden email]>

07/05/2005 10:00 AM

       
        To:        <[hidden email]>, <[hidden email]>, "Alvin Wang" <[hidden email]>
        cc:        
        bcc:        
        Subject:        Re: empty tag



We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.
 
In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.
 
--oren
----- Original Message -----
From: [hidden email]
To: [hidden email] ; [hidden email]
Cc: [hidden email]
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag


HI


If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************

Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

VP Marketing IT Asset Enterprise Technologies
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

My opinion and what I would find useful:

if (tag already set)
{
  replace old value if a new non empty value is present
 never allow duplicate tags in the msg
}

Instead of numerous QF users to be checking and setting..it is better
to factor this in QF.
the issue of ambiguity may be resolved whenever
QF rejects a tag/value set operation by logging
"QFEONP QF Error Op Not Performed...tag without value cannot be added"
"QFEONP QF Error Op Not Performed...tag cannot be added for this msg"
"QFEONP QF Error Op Not Performed...tag value cannot be added in the
given format"
to a special QFE.log file
On 7/5/05, Oren Miller <[hidden email]> wrote:

> My concern is how to handle the situation where the field already exists.
> If field 58 is set in the message, and I set it again with a field that has
> an empty tag, what does this mean?  Does it mean that I ignore the new field
> and retain the old value?  Or do I remove the old field from the message
> completely.  In which case setting a field with an empty tag is the same
> behavior as calling removeField.  Both of these behaviors feel a little
> surprising to me.  I'd be interested in hearing other opinions on this.
>  
> --oren
> ----- Original Message -----
> From: Alvin Wang
> To: Oren Miller
> Cc: [hidden email] ;
> [hidden email]
> Sent: Tuesday, July 05, 2005 9:40 PM
> Subject: [Quickfix-developers] Re: empty tag
>
>
> Oren, I can understand where you are coming from. It makes total sense if QF
> throws NoTagValue exception in this case. However, I just feel it will add
> workload to the developers and the production may become disruptive.
>
> Thanks
> Alvin
>
>
>
>
> "Oren Miller" <[hidden email]>
>
> 07/05/2005 10:00 AM
>        
>         To:      
> <[hidden email]>,
> <[hidden email]>, "Alvin
> Wang" <[hidden email]>
>         cc:        
>         bcc:        
>         Subject:        Re: empty tag
>
>
> We could, although more likely I would throw a NoTagValue exception.  I
> don't much like the idea of having QF silently ignoring a field that the
> developer would be expecting to go out in the message (much like I don't
> like the current behavior).  I can imagine the head scratching that would go
> on if they added a field and then found it mysteriously absent in the logs.
>  
> In either case if you have a field that might contain a blank value, I would
> suggest checking it before adding it to a message.
>  
> --oren
> ----- Original Message -----
> From: Alvin Wang
> To: [hidden email] ;
> [hidden email]
> Cc: Oren Miller
> Sent: Tuesday, July 05, 2005 9:10 PM
> Subject: empty tag
>
>
> HI
>
> If I set a tag as below:
> message.set(new Text(text));
> and if the variable "text" is null. QF will include an empty tag 58. As a
> result, some FIX engine (such as QF itself) on the other end will reject the
> message.  Can QF skip including empty tag?
>
> Thanks
> Alvin
> **********************************************************************
> This e-mail message is intended solely for the use of the addressee. The
> message may contain information that is privileged and confidential.
> Disclosure to anyone other than the intended recipient is prohibited. If you
> are not the intended recipient, please do not disseminate, distribute or
> copy this communication, by e-mail or otherwise. Instead, please notify us
> immediately by return e-mail (including the original message with your
> reply) and then delete and discard all copies of the message. We have taken
> precautions to minimize the risk of transmitting software viruses but
> nevertheless advise you to carry out your own virus checks on any attachment
> to this message. We accept no liability for any loss or damage caused by
> software viruses.
> **********************************************************************
>
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Alvin Wang
In reply to this post by Alvin Wang

IMHO, can QF have a configuration for this behavior? Exception(strict) vs Ignore(forgiving)...

Thanks




"Oren Miller" <[hidden email]>
Sent by: [hidden email]

07/05/2005 10:16 AM

       
        To:        "Alvin Wang" <[hidden email]>
        cc:        <[hidden email]>, <[hidden email]>
        bcc:        
        Subject:        Re: [Quickfix-developers] Re: empty tag



My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.
 
--oren
----- Original Message -----
From: Alvin Wang
To: Oren Miller
Cc: [hidden email] ; [hidden email]
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws
NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks

Alvin




"Oren Miller" <oren@...>

07/05/2005 10:00 AM

       
       To:        <
[hidden email]>, <[hidden email]>, "Alvin Wang" <AWang@...>
       cc:        

       bcc:        

       Subject:        Re: empty tag




We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.

 

In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.

 

--oren

----- Original Message -----
From:
Alvin Wang
To:
[hidden email] ; [hidden email]
Cc:
Oren Miller
Sent:
Tuesday, July 05, 2005 9:10 PM
Subject:
empty tag


HI

If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************


Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Brian Erst
In reply to this post by Oren Miller
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Oren -

I'd definitely go with the NoTagValue exception method rather than
attempting to guess what the developer "really" wants.

You have the removeField method for the case of needing to strip a
field out of a message, so providing a backdoor way of doing that via
adding a "blank" value is redundant. It also isn't obvious that "blank"
= "delete".

Considering how many FIX engines choke on a missing tag value, I think
it's a good idea to default to not allowing it. I'd rather add a new
method (addBlankField or some such) or optional parameter (e.g.,
message.set(value, allowBlanks)) on the off chance that some weird FIX
implementation out there requires the existence of a tag even if there
is no value for it than allow what is normally considered "bad" FIX to
go out by default.

- Brian Erst
Thynk Software, Inc.

--- Oren Miller <[hidden email]> wrote:

> My concern is how to handle the situation where the field already
> exists.  If field 58 is set in the message, and I set it again with a
> field that has an empty tag, what does this mean?  Does it mean that
> I ignore the new field and retain the old value?  Or do I remove the
> old field from the message completely.  In which case setting a field
> with an empty tag is the same behavior as calling removeField.  Both
> of these behaviors feel a little surprising to me.  I'd be interested
> in hearing other opinions on this.
>
> --oren
>   ----- Original Message -----
>   From: Alvin Wang
>   To: Oren Miller
>   Cc: [hidden email] ;
> [hidden email]
>   Sent: Tuesday, July 05, 2005 9:40 PM
>   Subject: [Quickfix-developers] Re: empty tag
>
>
>
>   Oren, I can understand where you are coming from. It makes total
> sense if QF throws NoTagValue exception in this case. However, I just
> feel it will add workload to the developers and the production may
> become disruptive.
>
>   Thanks
>   Alvin
>
>
>
>
>        "Oren Miller" <[hidden email]>
>         07/05/2005 10:00 AM
>
>                
>                 To:      
> <[hidden email]>,
> <[hidden email]>, "Alvin Wang"
> <[hidden email]>
>                 cc:        
>                 bcc:        
>                 Subject:        Re: empty tag
>
>
>
>   We could, although more likely I would throw a NoTagValue
> exception.  I don't much like the idea of having QF silently ignoring
> a field that the developer would be expecting to go out in the
> message (much like I don't like the current behavior).  I can imagine
> the head scratching that would go on if they added a field and then
> found it mysteriously absent in the logs.
>    
>   In either case if you have a field that might contain a blank
> value, I would suggest checking it before adding it to a message.
>    
>   --oren
>   ----- Original Message -----
>   From: Alvin Wang
>   To: [hidden email] ;
> [hidden email]
>   Cc: Oren Miller
>   Sent: Tuesday, July 05, 2005 9:10 PM
>   Subject: empty tag
>
>
>   HI
>
>   If I set a tag as below:
>   message.set(new Text(text));
>   and if the variable "text" is null. QF will include an empty tag
> 58. As a result, some FIX engine (such as QF itself) on the other end
> will reject the message.  Can QF skip including empty tag?
>
>   Thanks
>   Alvin
>
**********************************************************************

> This e-mail message is intended solely for the use of the addressee.
> The message may contain information that is privileged and
> confidential. Disclosure to anyone other than the intended recipient
> is prohibited. If you are not the intended recipient, please do not
> disseminate, distribute or copy this communication, by e-mail or
> otherwise. Instead, please notify us immediately by return e-mail
> (including the original message with your reply) and then delete and
> discard all copies of the message. We have taken precautions to
> minimize the risk of transmitting software viruses but nevertheless
> advise you to carry out your own virus checks on any attachment to
> this message. We accept no liability for any loss or damage caused by
> software viruses.
>
**********************************************************************
>
>
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Alvin Wang
In reply to this post by Alvin Wang

Oren,

if we can discuss this issue in a more broader scope, can QF have a configuration to (dis)allow to handle "empty-tag" message received from counterparty?

Also, can the message.getFiled() method return null if a tag does not exist (or is empty)? rather than through a exception.
I have found catching this kind of exception is troublesome and I have to wrap it in my own methods for each different data types.

Thanks

Alvin




Alvin Wang

07/05/2005 11:16 PM


        To:        "Oren Miller" <[hidden email]>
        cc:        [hidden email], [hidden email]
        Subject:        Re: [Quickfix-developers] Re: empty tag<a href=Notes:///85256ECF0052C8A0/DABA975B9FB113EB852564B5001283EA/C47818933EC82E8B85257035004EB4BD>Link


IMHO, can QF have a configuration for this behavior? Exception(strict) vs Ignore(forgiving)...

Thanks




"Oren Miller" <[hidden email]>
Sent by: [hidden email]

07/05/2005 10:16 AM

       
        To:        "Alvin Wang" <[hidden email]>
        cc:        <[hidden email]>, <[hidden email]>
        bcc:        
        Subject:        Re: [Quickfix-developers] Re: empty tag



My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.
 
--oren
----- Original Message -----
From: Alvin Wang
To: Oren Miller
Cc: [hidden email] ; [hidden email]
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws
NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks

Alvin




"Oren Miller" <oren@...>

07/05/2005 10:00 AM

       
       To:        <
[hidden email]>, <[hidden email]>, "Alvin Wang" <AWang@...>
       cc:        

       bcc:        

       Subject:        Re: empty tag




We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.

 

In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.

 

--oren

----- Original Message -----
From:
Alvin Wang
To:
[hidden email] ; [hidden email]
Cc:
Oren Miller
Sent:
Tuesday, July 05, 2005 9:10 PM
Subject:
empty tag


HI

If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************




Reply | Threaded
Open this post in threaded view
|

RE: Re: empty tag

Steve Bate-5
In reply to this post by Brian Erst
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I vote this approach as the default behavior, possibly with a
configuration option for the other behaviors.

> -----Original Message-----
> From: [hidden email] [mailto:quickfix-
> [hidden email]] On Behalf Of Brian Erst
> Sent: Tuesday, July 05, 2005 9:46 AM
> To: Oren Miller; Alvin Wang
> Cc: [hidden email]; quickfix-developers-
> [hidden email]
> Subject: Re: [Quickfix-developers] Re: empty tag
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Oren -
>
> I'd definitely go with the NoTagValue exception method rather than
> attempting to guess what the developer "really" wants.
>
> You have the removeField method for the case of needing to strip a
> field out of a message, so providing a backdoor way of doing that via
> adding a "blank" value is redundant. It also isn't obvious that "blank"
> = "delete".
>
> Considering how many FIX engines choke on a missing tag value, I think
> it's a good idea to default to not allowing it. I'd rather add a new
> method (addBlankField or some such) or optional parameter (e.g.,
> message.set(value, allowBlanks)) on the off chance that some weird FIX
> implementation out there requires the existence of a tag even if there
> is no value for it than allow what is normally considered "bad" FIX to
> go out by default.
>
> - Brian Erst
> Thynk Software, Inc.
>
> --- Oren Miller <[hidden email]> wrote:
>
> > My concern is how to handle the situation where the field already
> > exists.  If field 58 is set in the message, and I set it again with a
> > field that has an empty tag, what does this mean?  Does it mean that
> > I ignore the new field and retain the old value?  Or do I remove the
> > old field from the message completely.  In which case setting a field
> > with an empty tag is the same behavior as calling removeField.  Both
> > of these behaviors feel a little surprising to me.  I'd be interested
> > in hearing other opinions on this.
> >
> > --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: Oren Miller
> >   Cc: [hidden email] ;
> > [hidden email]
> >   Sent: Tuesday, July 05, 2005 9:40 PM
> >   Subject: [Quickfix-developers] Re: empty tag
> >
> >
> >
> >   Oren, I can understand where you are coming from. It makes total
> > sense if QF throws NoTagValue exception in this case. However, I just
> > feel it will add workload to the developers and the production may
> > become disruptive.
> >
> >   Thanks
> >   Alvin
> >
> >
> >
> >
> >        "Oren Miller" <[hidden email]>
> >         07/05/2005 10:00 AM
> >
> >
> >                 To:
> > <[hidden email]>,
> > <[hidden email]>, "Alvin Wang"
> > <[hidden email]>
> >                 cc:
> >                 bcc:
> >                 Subject:        Re: empty tag
> >
> >
> >
> >   We could, although more likely I would throw a NoTagValue
> > exception.  I don't much like the idea of having QF silently ignoring
> > a field that the developer would be expecting to go out in the
> > message (much like I don't like the current behavior).  I can imagine
> > the head scratching that would go on if they added a field and then
> > found it mysteriously absent in the logs.
> >
> >   In either case if you have a field that might contain a blank
> > value, I would suggest checking it before adding it to a message.
> >
> >   --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: [hidden email] ;
> > [hidden email]
> >   Cc: Oren Miller
> >   Sent: Tuesday, July 05, 2005 9:10 PM
> >   Subject: empty tag
> >
> >
> >   HI
> >
> >   If I set a tag as below:
> >   message.set(new Text(text));
> >   and if the variable "text" is null. QF will include an empty tag
> > 58. As a result, some FIX engine (such as QF itself) on the other end
> > will reject the message.  Can QF skip including empty tag?
> >
> >   Thanks
> >   Alvin
> >
> **********************************************************************
> > This e-mail message is intended solely for the use of the addressee.
> > The message may contain information that is privileged and
> > confidential. Disclosure to anyone other than the intended recipient
> > is prohibited. If you are not the intended recipient, please do not
> > disseminate, distribute or copy this communication, by e-mail or
> > otherwise. Instead, please notify us immediately by return e-mail
> > (including the original message with your reply) and then delete and
> > discard all copies of the message. We have taken precautions to
> > minimize the risk of transmitting software viruses but nevertheless
> > advise you to carry out your own virus checks on any attachment to
> > this message. We accept no liability for any loss or damage caused by
> > software viruses.
> >
> **********************************************************************
> >
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

RE: Re: empty tag

Jain, Anil
In reply to this post by Alvin Wang
My two cents.
From business point of view, I believe an empty (standard) tag has no meaning, so I believe, the current behavior of allowing an empty tag is merely a  technical fix to avoid the contentious issues you mention below  viz.
  i) Missing an expected tag
 ii) Removing an existing valid value tag
iii) Containing an incorrect (previous) value
 
Possible Resolutions:
A) Configuration of allowing/disallowing in general carries the same surprise elements
B) Configuring for a specific tag may be more desirable as it is a published and managed resolution
C) Configuring for a specific tag for a New/Cancel/Replace) may be even more desirable
D) Configure to simply ignore empty values
E) Configure to ignore empty values with warning
 
In my view default behavior as it exists now and with C and E  or B & E is desirable.
 
Thanks,
 
Anil
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Oren Miller
Sent: Tuesday, July 05, 2005 10:17 AM
To: Alvin Wang
Cc: [hidden email]; [hidden email]
Subject: Re: [Quickfix-developers] Re: empty tag

My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.
 
--oren
----- Original Message -----
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks
Alvin




"Oren Miller" <[hidden email]>

07/05/2005 10:00 AM

       
        To:        <[hidden email]>, <[hidden email]>, "Alvin Wang" <[hidden email]>
        cc:        
        bcc:        
        Subject:        Re: empty tag



We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.
 
In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.
 
--oren
----- Original Message -----
From: [hidden email]
To: [hidden email] ; [hidden email]
Cc: [hidden email]
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag


HI


If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************




------------------------------------------------------------------------------


This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately.


This E-Mail (including any attachments) has been scanned for viruses. It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened. However, it is the responsibility of the recipient to ensure that it is virus free. The sender accepts no responsibility for any loss or damage arising in any way from its use.


E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.


====================================================



Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Oren Miller
In reply to this post by Alvin Wang
The configuration setting ValidateFieldsHaveValues already exists.
 
Returning null is not really an option in the C++ api.  I'm not really sure if always having to check for null before using a field really saves any trouble anyway.  The engine is designed to catch the exception and send an appropriate reject message if not present.  Maybe I'm not understanding your particular case, but I'm not really sure why you need to trap that exception in the general case.
 
--oren
----- Original Message -----
Sent: Tuesday, July 05, 2005 10:29 PM
Subject: Re: [Quickfix-developers] Re: empty tag


Oren,

if we can discuss this issue in a more broader scope, can QF have a configuration to (dis)allow to handle "empty-tag" message received from counterparty?

Also, can the message.getFiled() method return null if a tag does not exist (or is empty)? rather than through a exception.
I have found catching this kind of exception is troublesome and I have to wrap it in my own methods for each different data types.

Thanks

Alvin




Alvin Wang

07/05/2005 11:16 PM


        To:        "Oren Miller" <[hidden email]>
        cc:        [hidden email], [hidden email]
        Subject:        Re: [Quickfix-developers] Re: empty tag<A href="Notes:///85256ECF0052C8A0/DABA975B9FB113EB852564B5001283EA/C47818933EC82E8B85257035004EB4BD">Link


IMHO, can QF have a configuration for this behavior? Exception(strict) vs Ignore(forgiving)...

Thanks




"Oren Miller" <[hidden email]>
Sent by: [hidden email]

07/05/2005 10:16 AM

       
        To:        "Alvin Wang" <[hidden email]>
        cc:        <[hidden email]>, <[hidden email]>
        bcc:        
        Subject:        Re: [Quickfix-developers] Re: empty tag



My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.
 
--oren
----- Original Message -----
From: [hidden email]
To: [hidden email]
Cc: [hidden email] ; [hidden email]
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws
NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks

Alvin




"Oren Miller" <[hidden email]>

07/05/2005 10:00 AM

       
       To:        <
[hidden email]>, <[hidden email]>, "Alvin Wang" <[hidden email]>
       cc:        

       bcc:        

       Subject:        Re: empty tag




We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.

 

In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.

 

--oren

----- Original Message -----
From:
[hidden email]
To:
[hidden email] ; [hidden email]
Cc:
[hidden email]
Sent:
Tuesday, July 05, 2005 9:10 PM
Subject:
empty tag


HI

If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************




Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Alvin Wang
In reply to this post by Alvin Wang

Oren,

I use the same code base to deal with multiple counterpaties. We want to demoralize some fields and save them in our tables for future use. That means I only need to retrieve the values and save to DB. So sometimes I do not really care if it is Null or not for most of tags

Thanks
Alvin




"Oren Miller" <[hidden email]>

07/05/2005 11:45 AM

       
        To:        <[hidden email]>, <[hidden email]>, "Alvin Wang" <[hidden email]>
        cc:        
        bcc:        
        Subject:        Re: [Quickfix-developers] Re: empty tag



The configuration setting ValidateFieldsHaveValues already exists.
 
Returning null is not really an option in the C++ api.  I'm not really sure if always having to check for null before using a field really saves any trouble anyway.  The engine is designed to catch the exception and send an appropriate reject message if not present.  Maybe I'm not understanding your particular case, but I'm not really sure why you need to trap that exception in the general case.
 
--oren
----- Original Message -----
From: Alvin Wang
To: Oren Miller ; [hidden email] ; [hidden email]
Sent: Tuesday, July 05, 2005 10:29 PM
Subject: Re: [Quickfix-developers] Re: empty tag


Oren,


if we can discuss this issue in a more broader scope, can QF have a configuration to (dis)allow to handle "empty-tag" message received from counterparty?


Also, can the message.getFiled() method return null if a tag does not exist (or is empty)? rather than through a exception.
I have found catching this kind of exception is troublesome and I have to wrap it in my own methods for each different data types.


Thanks


Alvin




Alvin Wang

07/05/2005 11:16 PM


       To:        "Oren Miller" <
oren@...>
       cc:        
[hidden email], [hidden email]
       Subject:        Re: [Quickfix-developers] Re: empty tag
<a href=Notes:///85256ECF0052C8A0/DABA975B9FB113EB852564B5001283EA/C47818933EC82E8B85257035004EB4BD>Link



IMHO, can QF have a configuration for this behavior? Exception(strict) vs Ignore(forgiving)...


Thanks




"Oren Miller" <[hidden email]>
Sent by: [hidden email]

07/05/2005 10:16 AM

       
       To:        "Alvin Wang" <[hidden email]>

       cc:        <[hidden email]>, <[hidden email]>

       bcc:        

       Subject:        Re: [Quickfix-developers] Re: empty tag




My concern is how to handle the situation where the field already exists.  If field 58 is set in the message, and I set it again with a field that has an empty tag, what does this mean?  Does it mean that I ignore the new field and retain the old value?  Or do I remove the old field from the message completely.  In which case setting a field with an empty tag is the same behavior as calling removeField.  Both of these behaviors feel a little surprising to me.  I'd be interested in hearing other opinions on this.

 

--oren

----- Original Message -----
From:
Alvin Wang
To:
Oren Miller
Cc:
[hidden email] ; [hidden email]
Sent:
Tuesday, July 05, 2005 9:40 PM
Subject:
[Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if QF throws
NoTagValue exception in this case. However, I just feel it will add workload to the developers and the production may become disruptive.

Thanks

Alvin



"Oren Miller" <oren@...>

07/05/2005 10:00 AM

       
      To:        <
[hidden email]>, <[hidden email]>, "Alvin Wang" <AWang@...>
      cc:        

      bcc:        

      Subject:        Re: empty tag





We could, although more likely I would throw a NoTagValue exception.  I don't much like the idea of having QF silently ignoring a field that the developer would be expecting to go out in the message (much like I don't like the current behavior).  I can imagine the head scratching that would go on if they added a field and then found it mysteriously absent in the logs.


In either case if you have a field that might contain a blank value, I would suggest checking it before adding it to a message.


--oren

----- Original Message -----
From:
Alvin Wang
To:
[hidden email] ; [hidden email]
Cc:
Oren Miller
Sent:
Tuesday, July 05, 2005 9:10 PM
Subject:
empty tag



HI

If I set a tag as below:

message.set(new Text(text));

and if the variable "text" is null. QF will include an empty tag 58. As a result, some FIX engine (such as QF itself) on the other end will reject the message.  Can QF skip including empty tag?


Thanks

Alvin
********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************





Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Caleb Epstein-3
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

On 7/6/05, Alvin Wang <[hidden email]> wrote:

> I use the same code base to deal with multiple counterpaties. We want to
> demoralize some fields and save them in our tables for future use. That
> means I only need to retrieve the values and save to DB. So sometimes I do
> not really care if it is Null or not for most of tags

Then use the FieldMap::isSetField method to check if the field is
populated before trying to fetch it.

--
Caleb Epstein
caleb dot epstein at gmail dot com


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: Re: empty tag

Bugzilla from Joerg.Thoennes@macd.com
In reply to this post by Steve Bate-5
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Steve Bate wrote:
> I vote this approach as the default behavior, possibly with a
> configuration option for the other behaviors.

So do I. NoTagValue exception is the best way to handle. An optional parameter to the
set() method sounds like a good idea.

Cheers, Jörg

>>-----Original Message-----
>>From: [hidden email] [mailto:quickfix-
>>[hidden email]] On Behalf Of Brian Erst
>>Sent: Tuesday, July 05, 2005 9:46 AM
>>To: Oren Miller; Alvin Wang
>>Cc: [hidden email]; quickfix-developers-
>>[hidden email]
>>Subject: Re: [Quickfix-developers] Re: empty tag
>>
>>QuickFIX Documentation:
>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>Oren -
>>
>>I'd definitely go with the NoTagValue exception method rather than
>>attempting to guess what the developer "really" wants.
>>
>>You have the removeField method for the case of needing to strip a
>>field out of a message, so providing a backdoor way of doing that via
>>adding a "blank" value is redundant. It also isn't obvious that "blank"
>>= "delete".
>>
>>Considering how many FIX engines choke on a missing tag value, I think
>>it's a good idea to default to not allowing it. I'd rather add a new
>>method (addBlankField or some such) or optional parameter (e.g.,
>>message.set(value, allowBlanks)) on the off chance that some weird FIX
>>implementation out there requires the existence of a tag even if there
>>is no value for it than allow what is normally considered "bad" FIX to
>>go out by default.
>>
>>- Brian Erst
>>Thynk Software, Inc.
>>
>>--- Oren Miller <[hidden email]> wrote:
>>
>>
>>>My concern is how to handle the situation where the field already
>>>exists.  If field 58 is set in the message, and I set it again with a
>>>field that has an empty tag, what does this mean?  Does it mean that
>>>I ignore the new field and retain the old value?  Or do I remove the
>>>old field from the message completely.  In which case setting a field
>>>with an empty tag is the same behavior as calling removeField.  Both
>>>of these behaviors feel a little surprising to me.  I'd be interested
>>>in hearing other opinions on this.
>>>
>>>--oren
>>>  ----- Original Message -----
>>>  From: Alvin Wang
>>>  To: Oren Miller
>>>  Cc: [hidden email] ;
>>>[hidden email]
>>>  Sent: Tuesday, July 05, 2005 9:40 PM
>>>  Subject: [Quickfix-developers] Re: empty tag
>>>
>>>
>>>
>>>  Oren, I can understand where you are coming from. It makes total
>>>sense if QF throws NoTagValue exception in this case. However, I just
>>>feel it will add workload to the developers and the production may
>>>become disruptive.
>>>
>>>  Thanks
>>>  Alvin
>>>
>>>
>>>
>>>
>>>       "Oren Miller" <[hidden email]>
>>>        07/05/2005 10:00 AM
>>>
>>>
>>>                To:
>>><[hidden email]>,
>>><[hidden email]>, "Alvin Wang"
>>><[hidden email]>
>>>                cc:
>>>                bcc:
>>>                Subject:        Re: empty tag
>>>
>>>
>>>
>>>  We could, although more likely I would throw a NoTagValue
>>>exception.  I don't much like the idea of having QF silently ignoring
>>>a field that the developer would be expecting to go out in the
>>>message (much like I don't like the current behavior).  I can imagine
>>>the head scratching that would go on if they added a field and then
>>>found it mysteriously absent in the logs.
>>>
>>>  In either case if you have a field that might contain a blank
>>>value, I would suggest checking it before adding it to a message.
>>>
>>>  --oren
>>>  ----- Original Message -----
>>>  From: Alvin Wang
>>>  To: [hidden email] ;
>>>[hidden email]
>>>  Cc: Oren Miller
>>>  Sent: Tuesday, July 05, 2005 9:10 PM
>>>  Subject: empty tag
>>>
>>>
>>>  HI
>>>
>>>  If I set a tag as below:
>>>  message.set(new Text(text));
>>>  and if the variable "text" is null. QF will include an empty tag
>>>58. As a result, some FIX engine (such as QF itself) on the other end
>>>will reject the message.  Can QF skip including empty tag?
>>>
>>>  Thanks
>>>  Alvin


--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

MsgType field values in DD XML?

Steve Bate-5
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi,

Is it intentional that the MsgType field doesn't
have field values specified in the DD XML? I'm working on a
tool where I'd like to display user-friendly names for the
MsgType as I noticed there's no field values for that field.

Steve




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: MsgType field values in DD XML?

Oren Miller
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

It looks like FIX43.xml and FIX44.xml do have them, so I don't see a problem
with adding them to the earlier versions.  You can however always get those
names from the Message element regardless.

--oren

----- Original Message -----
From: "Steve Bate" <[hidden email]>
To: <[hidden email]>
Sent: Friday, July 08, 2005 11:26 AM
Subject: [Quickfix-developers] MsgType field values in DD XML?


> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> Is it intentional that the MsgType field doesn't
> have field values specified in the DD XML? I'm working on a
> tool where I'd like to display user-friendly names for the
> MsgType as I noticed there's no field values for that field.
>
> Steve
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by
> HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Quickfix-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers