Ignoring Specific Warnings or Warning Instances

Ben W.
King of Prussia, PA

Jun 21, 2016
8 Posts

0 ✔  |  ✗ 0  

Re: Ignoring Specific Warnings or Warning Instances

Hello,

I was wondering if during the build process it would be possible to have ATEasy suppress/ignore specific warning codes or even specific instances of warnings if there are multiple warnings of the same warning code. For example, a driver form variable is not referenced in a program but another program may reference that variable. The unused variable warning appears in the program that doesn't use the variable. I know I can disable all warnings or just unused variable warnings, but that could hide warnings that I'd like to be shown.

References:
https://msdn.microsoft.com/en-us/library/dn782850.aspx
http://stackoverflow.com/questions/857741/suppressing-obsolete-warnings-in-vb-net

Thanks,

Ben

Solution Available
DrATEasy (Ron Y.)
Mission Viejo, CA

Jun 23, 2016
358 Posts

1 ✔  |  ✗ 0  

Re: Ignoring Specific Warnings or Warning Instances

There is no way to mask the unused variable warning, except from adding a refrence to it in the driver.

I think we can improve this by adding ignore flags similar to the one the C compiler has. I will add it to our suggestion list.

We probably need two ignore flags:  In the case of private driver variable, the warning is always correct since the variable cannot be reached, if  the variable is a public driver then it could be that another project will be using it. In any case, If you are defining a driver variable to be used from outside of the driver, it's a good practice to have a set/get commands/procedures to use it, instead of accessing it directly.



Please Note
You need to have a M@GIC account to participate in the Forums.
Not yet registered on our website? Click here to register today!

All content, information and opinions presented on the Marvin Test Solutions User Forums are those of the authors of the posts and messages and not Marvin Test Solutions'. All attachments and files are downloaded at your own risk. [Read More]