Plex 2E

When building existing panels for C# I see lots of errors in the message log similar to the example below.

GEN59571
"Grid columns BusinessMiles and ExpenseType.Description have duplicate column numbers."

I think that this is new, what is the significance?

Hi there Matt,

You would get the same messages if you generated your panels for Java as well.

This message is produced because two or more columns have duplicate values in the Column Number property. I find that in many cases where this error occurs, one column will have a Column Number defined locally (L) and another will have the same value, but it will be calculated (C). The only way to get locally defined values against columns, from what I can tell, is to manually enter them - it's not like the panel editor modified the property based on something you dragged and dropped on the panel to change the order. I think normally the Panel Editor uses a rule to define the actual visual order of columns - 'L' values override 'C' values. Although the Java and C# generators follow this same rule, they are a bit more annoying about letting you know about it.
So basically, the message is entirely benign, it's just telling you that you might end up with a different column order than you might have expected. I remember being QA on the Java Client project back in the day and having an argument with the developer as to whether this message should be an error or a warning. I wanted it to be a warning, so I obviously lost the argument.

Can you confirm based on the error messages you are seeing, whether have duplicate Column Number properties for fields? If so, I think we have three choices:

(1) You are happy to fix the duplicate Column Numbers for your panels (either by explicitly defining all column orders (L) or putting them back to their default order (C)).
(2) We change the severity of the message to Warning or Informational. This would be my preferred solution.
(3) We modify the way the C property logic works so that there is no possibility of duplicate columns existing for a grid. This doesn’t appeal to me because the logic hasn’t changed since the dawn of Obsydian, and it might have an impact on existing customers.

What do you think?

-Rob

I used the Java generator for 7 months earlier this year for a project and this was quite a frustrating error message to get.

Everytime (Probable wasn't, just felt like it) new fields were added I'd end up with some sort of duplicate. Many times it was fields that were to be hidden on the panel design but they still clashed. I believe I raised an enhancement requested to be able to renumber the columns in the order they are in the grid. (Well I think I did - A sort of Q5 or Q0 in 2E). Otherwise you are looking for the two clashing fields.......

I work to a zero tolerance policy on build messages to ensure technical accuracy of my applications. The BIG question is why the developer chose to ignore your preference. Was there a behaviour that was so unpredicatable if could be bad or was it against some Java disciples view point for the A**** retentive.

Therefore my preferred solution if this can cause unpredicable behavious (i.e. ordering not the same as designed).
Warning if the columns are both displayed and
Supressed (Not interested) if the clashing columns are hidden.

That way people can chose to accept it. People like me will still fix them up but the function wil still generate and build. In fact it became a routine thing for me but for people migrating a project with potentially 10's or 100's or dare I say if 1,000's of grids I could see it being a frustrating exercise.

If no real issues can be concluded. Forget about telling me. The C++ panel generator doesn't afterall :tongue

Lee.

Rob, Lee,

I've not been a big user of Java in the past and so was unaware of this. If the message is intended to warn programmers that they may run into problems if they try to manipulate grid behaviour using API calls but the function will build and run, then severity should be downgraded to a warning.

Perhaps consult a little wider on this?

Hi Matthew and Lee,

I agree that this error has gone more annoying with the introduction of the WPF client generator. I logged an issue about this.

Thanks,
Olga