Abominable Code

#1 Err, what?

#2 GuiDirectoryTreeCtrl::buildIconTable isnt much better...

They need to be made dynamic... No ideas how though.

And hehehehe "Oh my gosh"... I'm yet to hear that said. :)

-- Ricky

#3 Bah! It's not elegant, but calling it abominable is a bit too much, imho... Have a look at the mesh and fluid rendering part to see really bad code. But I've seen much worse code out of Torque in my my carrier to be squeamish.

#4 @Ricky: Yes, it's a hack and tied way too closely with the engine.

@Alberto: Check out the code... you'll see why I called it that. =) And yeah, there are definitely more evils lurking, but many have a long legacy and are not particularly surprising -- this code is relatively new (1.4) and has clearly just been thrown together (a little too) quick.

I'm going to need to fix it. I've got some ideas (one: perhaps a bitmap array, like the window frames) but I would like some input before I jump into it, since I'm hardly an expert with the engine code. So all you engine gurus, throw some ideas my way -- let me know what you think the best way to fix this is. In particular, Ben Garney, if you're reading this, I'd appreciate some input from you. Thanks! =)

#5 Ok, so it appears that there is already an initialization mechanism of sorts available for the script. There is a console method called "buildIconTable" (strangely enough) which takes a string as an argument. However, the one place that references this is commented out!.

In guiEditorGui.gui:

//----------------------------------------
// defines the icons to be used in the tree view control
// provide the paths to each icon minus the file extension
// seperate them with : 
// the order of the icons must correspond to the bit array defined
// in the GuiTreeViewCtrl.h
function GuiEditorTreeView::onDefineIcons(%this)
{
   //%icons = "common/ui/shll_icon_passworded_hi:common/ui/shll_icon_passworded:common/ui/shll_icon_notqueried_hi:common/ui/shll_icon_notqueried:common/ui/shll_icon_favorite_hi:common/ui/shll_icon_default:";
   //GuiEditorTreeView.buildIconTable(%icons);
}

So yeah, I'd certainly like to know a little more history here. Why isn't this code used? For that matter, why is it implemented this way? I would have expected a string member ( something like "mIconList") made available to script in initPersistFields(), which GuiTreeViewCtrl would then use to automagically initialize itself, obviating the need for onDefineIcons() and buildIconTable() in the script.

Any ideas?

#6 Ten points for "obviating" !!!

#7 Sweet! =D

Wait... what do I do with the points???

#8 You can trade 'em in for vCredits !

.. or light them on fire and juggle them.

#9 LOL!!! By all means, let's light something on fire while we're waiting for some official input! Not gonna juggle anything though! =P

*Goes to find some lighter fluid*

#10 *bump* Hope to see some input on this....