Deprecated if_v1 may not correctly work on v5.5.6 or later

So have macros using deprecated code (it was working fine). With v5.5.7, it finally broke. So just an FYI for anyone else using deprecated code, this won’t work anymore.

if_v1_deprecated "${!COL5}" != "Create"
   do something here

It will still go into do something here even if COL5 = Create. The quotes on the left side of the equation is causing the issue, not exactly the deprecated command. But I think the quotes on the left was necessary with the deprecated command (or a much earlier version). A simple update fixed it for me.

if_v2 ${!COL5} != "Create"
   do something here

@admin, not sure if you want to address this is a bug. If only to be consistent with this from the What’s New.

  • Removed: Deprecated commands removed from the command drop down. But the commands itself continue to work just as beforee. And you can still edit and add these commands in the source code view tab.

But I think anyone still using code as old as the one I still have should be updating anyway.

As always, thanks for new features. And more importantly, it’s been overall very stable for us the past few months (that’s why deprecated code got left behind).

Thanks for the hint! Since there is a good workaround (= use new commands) we will probably not fix this if_V1 issue anymore.

1 Like

I have almost the same, but the trick for me was that it was going wrong silently, and i didn’t notice it for some time.
See screenshot:

I had a check for 0 in some field, and appeared to be the code related to this check stopped executing.
Appeared to be, that this gotoif_v1_deprecated command doesn’t check correctly after latest updates. BTW that wasn’t me who made it into brackets, it was auto-refresh during some update, i guess.

How to fix: for me worked to switch to gotoif_v2 and remove brackets. Same worked for if_v1_deprecated -> if_v2.

From one side that was an unexpected surprise to see my test tells me it’s OK while it was actually not. On the other side - time to review cases has come. I assume if that would be more explicitly told to users (that they should recheck cases and update faulty places) - that would be very kind.

Thanks for the useful report! We did not expect if_v1 to fail with this update, that is why there was no warning. In hindsight the issue was that if_v1 and all other _v1 commands were no longer in our QA test suite, so this regression bug remained unnoticed.

Remove all deprecated commands, have not sense to continue to use deprecated commands.

New commands are better.

That’s reasonable. But everywhere in docs and forum written that old commands will still work as they were and that sounds like no need to change. At first they were working, and new commands were not the same, so to keep working one should have changed logic of testcase and not just command. But now i see i should follow your way.

For folder test case i use a good solution

I switch to hard drive mode and inside the folder i rename macro with number


In this mode i can move the order or macro in easy way.

Old test case sometimes stucked, the new folder test case working better.

This works, i agree. It’s not the easyest way, but works. I avoid duplicating cases. Less cases - easier to support. I re-use 1 case if that is possible. In this idea there are two ways to implement: old-style scenarios (more comfortable for me now) and testcases-as-suites that contain only “run” command with calls to other testcases. This also works, but a bit less convenient. Check my replies in this topic for details: other topic

I use a folder with the “fuctions” that I use inside the macro with run command in this mode I can not copy al macro in every folder test case.

When i need a function I create a simple macro with command and i load it inside the macro with run command and i save all function in a folder.