View Single Post
 
Old 02-14-2018, 02:44 PM
FreakaZoid2 FreakaZoid2 is offline
Senior Member
 
Join Date: Jul 2009
Posts: 330
Default

Quote:
Originally Posted by Norrit View Post
Problem isn't the xml files, problem is that you do business logic in a UI!
Since you store the object data already in the treeview you don't need the array. It's not a matter of using both, it's a matter of choosing 1 and stick to that (or refactor).
Personally I would have been happy to just use GUIID since the field only has one real purpose, and that is to give the other real client program a value to assign to each xml element. it is a home build menu processor that reads the xml files and build a menu for the users to interact with. Since these xml files have already been sent to clients and they can add in custom items that are based upon these xml files id value, I cannot change these xml files id tags. So in the past 8-9 yrs anytime we needed to make a change it has always been done manually and occasionally a duplicate entry got put into the works. That is why I decided to just write up this program to allow us (other devs, support) to add (correctly) any new items we may need as time goes by. For example, the new 1095 processing/printing was manually added a couple of years back and the xml file was sent out to our clients as a patch.
And now that I have gone down this long road according to the Dev (.Net, C#), who just came by to ask me a question about another program, said that the menu processing application reads those numbers as a string and a GUIID will actually work. So heck with the array idea.