For the BOX we have <X> <Y> <T> <L> <color> <bordercolor> but I think it would usefull to have a <bordersize> argument too. Maybe, some preset ones like 1 - 10 pixels This way you could get a thick border if you wanted or just the default as it is now if you don't specify it.

And while I'm thinking about, is there anyway to get an MD5 for files like you can for the bios on your chip?

Well, BOX represents a problem there, since the box is drawn using a 3-D rectangle, as a solid, then redrawn as a 3-D rectangle as a line object.

To do width, I'd have to redraw the line portion multiple times, and change the actual coordinates - not the simplest procedure.


Getting an MD5 from a file sounds like a good idea.

Nevermind the box idea then. It'd be way easier to make one box a solid color and then add another smaller one over it.
-----------

If you add a MD5 function that'd be cool cause then we could, for instance have an update ActionScript that would check the MXM and Menu.xmls for their MD5 and know if they are unedited. You could even try to Hard Code the MD5 checksums for those files (the ones you package with the releases) Then when MXM is loading or right after it does, checks them to see if they're different. If they are then everything goes as normal. If they're the same, it triggers an ActionScript prompting the user with New Version Detected and allows then to edit the default files.

Even better, it resets menu cache whenever MD5 for menu.xml (or mxm.xml if the menu is defined in there) changes.

Now just need an automated way of detecting when games are added.
*Somewhere:
Keep a list of all subfolders present for every AutoDir menu item.
At startup, check the dir listing to see if anything is added/removed, and change accordingly.
Make Recurse="False" default, or Recurse="Smart" (like I mentioned before)

that is a good idea.

MD5 MXM.xml = default then its a New Version so Goto Update
MD5 MXM.xml = different it not new so goto Cachmenu
XMLGetValue Cachmenu.xml MD5 (<md5>md5 of itself</md5>) = same the goto conitinue
if its different reset and append new md5

Hey BenJeremy,

The box with variable width might be easier than you think. You just do a loop using the borderwidth as the number of iterations, adjusting the coordinates for each loop then use D3DPT_LINELOOP for the D3DPRIMITIVETYPE. You can draw a filled or empty box this way. This is what I'm doing -tell me if you need the code.


<edit>
I hope you don't take this as intruding in your turf, just wanna help in anyway I can -though I got a lot of problem on my own
</edit>

QUOTE (flattspott @ Jan 21 2004, 11:47 PM)

that is a good idea. MD5 MXM.xml = default then its a New Version so Goto Update MD5 MXM.xml = different it not new so goto Cachmenu XMLGetValue Cachmenu.xml MD5 (<md5>md5 of itself</md5>) = same the goto conitinue if its different reset and append new md5

Nothing can store an MD5 of itself because it changes the MD5

QUOTE (geniusalz @ Jan 22 2004, 01:17 AM)

QUOTE (flattspott @ Jan 21 2004, 11:47 PM) that is a good idea. MD5 MXM.xml = default then  its a New Version so Goto Update MD5 MXM.xml = different it not new so goto Cachmenu XMLGetValue Cachmenu.xml MD5 (<md5>md5 of itself</md5>) = same the goto conitinue if its different reset and append new md5 Nothing can store an MD5 of itself because it changes the MD5

That's true.

I might make an MD5 available via a different means, though. It probably wouldn't be too hard to add it internally, when it parses the file.

Okay then, about this.

How about appending an MD5 to a file Checking it and storing it as a variable. Then deleting the MD5 node and saving the file backout and then Check the MD5 again.

QUOTE (flattspott @ Jan 22 2004, 12:16 PM)

Okay then, about this. How about appending an MD5 to a file Checking it and storing it as a variable. Then deleting the MD5 node and saving the file backout and then Check the MD5 again.

Well, I'd rather just provide a function to take an XML handle and return the MD5 for it (from last load or save).