Issues with exporting SpellInfo from new file types

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Attempt to Export to xml the SpellInfo data, possibly AbilityInfo data as 
well.

What is the expected output/behaviour? What do you see instead?
Proper XML file.

What version are you using? On what operating system?
64-bit version, Win7 Pro 64-bit

Original issue reported on code.google.com by doomer18 on 4 Oct 2010 at 1:12

[GoogleCodeExporter]

Apparently when exporting, now, it's attempting to cast the "Thing" object to 
ListViewItem type.
I'm not sure how to resolve this one, personally.

Original comment by doomer18 on 4 Oct 2010 at 2:35

[GoogleCodeExporter]

Was working on a patch, however the cross-thread error popped up again in 
ExportThings().  Noting this here.  Still working on something.

Original comment by doomer18 on 5 Oct 2010 at 3:35

[GoogleCodeExporter]

Woot, working on a patch now....

Problem solved, including the cross-threading potential problem with exporting 
selected items via context menu.
Basically what happens is if you select Export to file immediately after 
opening a dat without anything selected, the "Focused" member variable returns 
false, because the TabPage/ListView doesn't actually have focus yet.

Added in a few sanity checks, had to run through the same deal with the Context 
Menu for Export All and Export Selected.  Tested with dats with TabPages (new 
spell/ability combined info) and those without (old Spell Info).

The cross-threading issue was resolved by adding a Global storage variable 
ListViewItems_ that basically is designated to be an array that just gets 
copied into from the existing ListView that we're copying from.  Only problem I 
see, is I never free up the extra memory utilized by the copy because from 
within the thread I don't want to Clear it all out.  Also, array worked better 
I thought than using a ListView seeing as how the CopyTo function requires an 
Array.

All in all, take a peek at it.

Original comment by doomer18 on 5 Oct 2010 at 5:08

Attachments:

• DataBrowserFix.patch

[GoogleCodeExporter]

Whoops. Some stuff was shuffled around to handle the multi-type DATs, but I 
only went so far as to see that the context menu still worked (which it did - 
the only cross-thread error I got was from the PWD.Close()).

Regarding your points:
1) It's odd that Focused is false - I guess it depends on where/how you're 
opening the context menu (I right-click on an item in the view, which 
automatically gives it focus). I guess the main point is that apparently there 
is no clean way of getting the relevant control from within a context menu's 
Click event (well, none that I could find quickly anyway). I guess I'll need 
something other than the Focused property :-)
2) I'll have to look into the cross-thread thing. I'm assuming it's the 
ListViewItem accesses? I guess it makes more sense to change ExportThings() to 
take a ThingList, avoid the issue altogether. Just not sure how long it takes 
to do the get-Things-out-of-Items/SelectedItems operation (it's currently 
inside the thread because I thought it took a while, probably longer than the 
Save operation). Maybe the export could just be de-threaded completely - would 
have to see how long an export of a larger DAT (e.g. armor/weapons) takes (UI 
would be unresponsive during the export).
3) You seem to have changed the semantic of the Export button - it will now 
export differently-typed Things separately. That is NOT the intention - the 
Export button is supposed to be a "pure" XML export of the DAT's contents.

Original comment by tim.vanholder@gmail.com on 5 Oct 2010 at 8:42

[GoogleCodeExporter]

1) Focused is only false when using the Button to click export before selecting 
anything in the TabPage/ListView, for the ContextMenus I still use the Focused 
property.
2) Yes, it's the ListViewItem accesses from within the anonymous delegate 
thread you create.  They way I have it currently still functions as normal.
3) The ExportThings() function uses a foreach on ListViewItems and ListViewItem 
itself is a descendant of IEnumerable anyway, all I did was copy the ListView 
list over to an array that's not assosciated with the control itself. I haven't 
touched ExportThings() at all, so I'm confused by what you mean with the "pure" 
XML export thing.  I'll check the code with things that aren't in a ListView 
real quick and report back.

Tested with other items, such as a Map, and it appears to function normally, so 
maybe you can explain what you mean.  I'm guessing you mean because I use an 
if, but because it's split between "stuff with TabPages" and "stuff without 
TabPages" this was the only way I saw to accomplish a fix.

While we're on the subject of exporting stuff, scragg from ffxiah.com mentioned 
problems with Images exported via XML.  Specifically when exporting the Armor 
Item Dat contents, the images within the xml (the base64-encoded ones) seemed 
to work fine until about halfway through and the images themselves got "cut in 
half".  I had to Export All Images separately specifically for him back in 
September to get the Armor Icons he needed for displaying on FFXIAH.com.  Not 
sure if you know how to resolve that one or not as I don't even know where to 
begin.  This however was with a modified version of the code prior to your most 
recent update, so I don't know if the issue still exists currently or not to be 
honest.

Original comment by doomer18 on 5 Oct 2010 at 2:26

[GoogleCodeExporter]

1) Ah OK, so that's not really relevant since the button's processing is not 
related to the listviews anymore.
2) And this is in VS2008? I'm pretty sure I ran an export and did not get a 
cross-thread issue from the listviewitem accesses.
3) I mean that the button, as opposed to the context menu, is supposed to 
export the items as they were read from the DAT, without caring what listview 
they were put in (and to put them all in a single output file). Your code for 
the button runs ExportThings (which presents the user with a Save File dialog) 
multiple times, once for each listview. If at some point there is support for a 
DAT with intermixed types of things, even accumulating Things from all 
listviews before calling ExportThings() would still produce a different item 
order.

Anyway, my intent is to adjust ExportThings() to take a ThingList instead of an 
IEnumerable. Then the button keeps its simple invocation, and the context menus 
need to gather the listviewitem tags to pass them along.

As for the item images, scragg hasn't mentioned anything about that, so I 
assume it's not an issue anymore for him. Anyway I would be surprised if the 
export itself was somehow failing to export image data properly halfway through 
(for one thing, it would also affect the Item Data Comparison utility and that 
seemed to work fine after the Armor DAT fix) - but I'll check to make sure.

Original comment by tim.vanholder@gmail.com on 5 Oct 2010 at 2:46

[GoogleCodeExporter]

I also see that I could/should be using ContextMenu.SourceControl instead of 
finding the Focused listview. I'll see when I can find the time to work on this.

Original comment by tim.vanholder@gmail.com on 5 Oct 2010 at 3:10

[GoogleCodeExporter]

Think things are fixed in revision 789.
Checking armor dat export just to be sure, but it's looking fine so far.

Original comment by tim.vanholder@gmail.com on 5 Oct 2010 at 5:24

[GoogleCodeExporter]

Tested armor dat export using attached XSLT transform, which produces a simple 
HTML with embedded PNG images (works in firefox and opera, not sure about IE or 
chrome).
Exported FR and JP armor DATs, icons all looked fine.
Marking this as fixed; will prepare 0.9.9.1 bugfix release.

Original comment by tim.vanholder@gmail.com on 5 Oct 2010 at 6:06

• Changed state: Fixed

Attachments:

• item-overview.xslt