This is a tough one.

My go to solution is a stored procedure as you can break the comma delimited string into its parts and use the view to look and return the 'true' value...and not everyone has the ability to use stored procs for a variety of reasons.

The next thought that comes to mind is a subreport. Since there is a limit of 8 strings you could use the SPLIT function to create an array of selected codes and assign them formulas (which would be the variables...more later) and then you could link the formulas to the subreport as parameters and have the parameters link to the view, which would then display the 'correct' values for the report.

hopefully a quick example will be helpful:
//first formula in the main report to split the string and populate the variables
shared stringvar c1:="";
shared stringvar c2:="";
shared stringvar c3:=""; //continue for all 8
local stringvar array sp:=split({?parameter}, ",");
if ubound(sp)>0 then c1:=sp[1];
if ubound(sp)>1 then c2:=sp[2];
if ubound(sp)>2 then c3:=sp[3]; //etc...fill the shared variables
"" //will hide the output of the formula

several other formula will be created that look like:
//lets call the formula p1-p8
shared stringvar c1

then, I am hoping as this might not work, and you will know really quick...
create the subreport with 8 paramaters, call them say, p1-p8
Link the subreport to the formula with p1 in the main report linking to p1 in the subreport.

for complete simplicity, I would create 8 commands in the subreport like:
select * from table where lookup_column = {@p1}//changing the parameter for each parameter

it's worth try. I am not sure if it will work as the formulas in the main report are only 'initialized' at run time, which might be too late for CR.

HTH

Could be user desire. They don't want to have 8 inputs.