EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

The new forum is online, hope you enjoy it!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Roman

Pages: 1 ... 127 128 129 130 131 [132] 133 134 135 136 137 ... 165
2621
clrmame Discussion / Re: clrmamepro 4.00a released
« on: 02 September 2011, 10:44 »
yeah yeah...first of all...I'm on holiday, no cmpro work till end of month...
secondly...I currently have this discussion with Oddie about *that* example...

Cmpro doesn't set any font, so it uses the standard system font for the controls / dialog fields / text outputs. Seems to be a font related thing on their systems....however the created files should be fine...just a display issue based on missing characters in their font...

I may look at this end of september ...sounds like I need to allow font selection or something...no idea...

2622
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 23:45 »
as I said... structures are bad, not data. 7z most likely only unzips to memory, calcs the cec32 and compares it against the stored one. Winzip got an option for a detailed analysis and found the bad extrafield data.

2623
clrmame Discussion / clrmamepro 4.00a released
« on: 01 September 2011, 21:39 »
clrmamepro 4.0a

fixed: crash in filedialog of "add Profile"
misc:  smarter is-bios-rom check if bios definitions hold identical checksums
misc:  fixed homepage and forum link in installer

2624
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 20:46 »
ok...I ran it through Winzip's analysis tools and your file is structure wise corrupt (this does not necessarily mean that you can unzip the data) and the reader will skip this file.

It seems that it holds too long extra field entries....I get messages like
 error: data (13062 bytes) exceeds remaining extra field (19 bytes)
for each file...

So...structure wise, your zip is bad. Rezipping (unzip, delete old archive, add to new zip) will most likely fix this issue.

2625
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 19:08 »
Another: if the host OS of a file in a zip archive is Macintosh, clrmamepro won't detect the file, works ok if host OS is FAT/NTFS/Unix. It worked fine in the previous version.

I stepped through the library and it returns a bad-zip return code...I've contacted the author to see what's wrong with it....

2626
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 09:52 »
hehehe..no problem....yeah..it's Windows which forbids the drag'n drop because 'two user levels' are used here.

One day I may make cmpro fully UAC compatible...but not now...maybe google shows me a hint on that....for a workaround...anyway...one less issue on my 4.00 reported issues list

2627
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 05:35 »
ok, I've downloaded the Casio - PV-1000 (20100525_cm).zip datfile from the dat-o-matic on my system. Drag'n drop worked fine on my Win7 with 32 and 64 bit versions.

Soo...which OS do you have? Maybe you should send me a zip which doesn't work for you.
In case of VISTA/Win7 be sure that cmpro is NOT installed (and you seem to use the installer version....) in an UAC controlled folder (e.g. NOT in c:\programs).
If you do install it there, you need to run it with "run as administrator"...

2628
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 01 September 2011, 05:28 »
ok...I will check later this evening..Thanks for providing the information.

By the way, if you're working with Vista or Windows7, any drag'n drop won't work if the application and the dropped files belong to different levels of UAC. So for such OSes, be sure to not install cmpro in an uac controlled folder. But that also happened with cmpro 3.x already (and other software ;))
Anyway...I will check the drag'n drop...

2629
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 31 August 2011, 23:07 »
if drag'n drop doesn't work for you, your dropped file most likely isn't readable...please provide the zip/xml in question

2630
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 31 August 2011, 23:07 »
hmmm....a zipfile created on the mac shouldn't harm...I will check it..thanks

2631
News & Communication / clrmamepro 4.00 released
« on: 31 August 2011, 17:10 »
Finally...and after 8 years of a 3.x cycle....

clrmamepro 4.0

misc: full unicode build
misc: full support for UTF8 characters in file/folder names, files within
      archives (7z/rar/zip) and datfiles (XML and old format)

      The default encoding of xml datfiles is UTF8. The default storing method
      in archives is UTF8 (for zip, with no extra field usage). Current versions
      of Winrar, Winzip, 7z (just to name a few) support UF8 stored names. There
      might be other 3rd party tools (which some people use to rezip/share :))
      which might fail (they only work with local page encoding). Tough luck...

      All textfiles in the clrmamepro environment are now saved as UTF8. You
      can use your old setup, since it loads them in ASCII and saves them as
      UTF8. XML files are stored without a BOM (byte ordered mark), non-xml
      files with a BOM. You should not use newly written files with old
      versions of clrmamepro. I recommend a good texteditor to work with UF8
      datfiles, e.g. notepad++, available here http://notepad-plus-plus.org/

misc: completely switched to latest ziparchive library for all zip related
      operations. This includes reading, in-place renaming and no-recompress
      copy. This results in a faster rebuilder (no recompress) and faster
      rename operations (scanner). Actual scanning speed is roughly the same.
   
added: devices support, devices and device_ref elements are parsed, exported,
       an own system default path for devices can be added, select sets
       supports filtering by devices and device_refs

removed: included doucmentation, switching to online pdf docs soon
removed: Settings->Compressor->Zip, obsolete due to ziparchive usage
removed: Settings->Compressor->Oem/Ansi conversion, obsolete due to UTF8 switch
removed: Scanner->Advanced->
         detect sets in wrong sysdefpaths
         move sets to correct sysdefpath
         chd use sysdefault assignments
         use sysdefault paths for fix missing
         Such options are automatically enabled internally now if sysdefpaths
         are setup. The first two ones require an unneeded check+fix though.

misc:  aligned "allow not separated bios sets" & "split bios sets"
misc:  directly jump to profiler or settings instead of prompting
fixed: xml parser doesn't handle multiple comments on the same line correctly
fixed: dat resource tag export for non-xml datfiles is broken

2632
clrmame Discussion / Re: clrmamepro 4.00 released
« on: 31 August 2011, 05:32 »
ehe...looks like all testers did not see the crash when pressing the add button in the profiler window :)
....well...till it gets fixed simply use drag'n drop to add profiles.

2633
clrmame Discussion / clrmamepro 4.00 released
« on: 30 August 2011, 22:21 »
Finally...and after 8 years of a 3.x cycle....

clrmamepro 4.0

misc: full unicode build
misc: full support for UTF8 characters in file/folder names, files within
      archives (7z/rar/zip) and datfiles (XML and old format)

      The default encoding of xml datfiles is UTF8. The default storing method
      in archives is UTF8 (for zip, with no extra field usage). Current versions
      of Winrar, Winzip, 7z (just to name a few) support UF8 stored names. There
      might be other 3rd party tools (which some people use to rezip/share :))
      which might fail (they only work with local page encoding). Tough luck...

      All textfiles in the clrmamepro environment are now saved as UTF8. You
      can use your old setup, since it loads them in ASCII and saves them as
      UTF8. XML files are stored without a BOM (byte ordered mark), non-xml
      files with a BOM. You should not use newly written files with old
      versions of clrmamepro. I recommend a good texteditor to work with UF8
      datfiles, e.g. notepad++, available here http://notepad-plus-plus.org/

misc: completely switched to latest ziparchive library for all zip related
      operations. This includes reading, in-place renaming and no-recompress
      copy. This results in a faster rebuilder (no recompress) and faster
      rename operations (scanner). Actual scanning speed is roughly the same.
   
added: devices support, devices and device_ref elements are parsed, exported,
       an own system default path for devices can be added, select sets
       supports filtering by devices and device_refs

removed: included doucmentation, switching to online pdf docs soon
removed: Settings->Compressor->Zip, obsolete due to ziparchive usage
removed: Settings->Compressor->Oem/Ansi conversion, obsolete due to UTF8 switch
removed: Scanner->Advanced->
         detect sets in wrong sysdefpaths
         move sets to correct sysdefpath
         chd use sysdefault assignments
         use sysdefault paths for fix missing
         Such options are automatically enabled internally now if sysdefpaths
         are setup. The first two ones require an unneeded check+fix though.

misc:  aligned "allow not separated bios sets" & "split bios sets"
misc:  directly jump to profiler or settings instead of prompting
fixed: xml parser doesn't handle multiple comments on the same line correctly
fixed: dat resource tag export for non-xml datfiles is broken

2634
clrmame Discussion / Re: New Feature Request
« on: 29 August 2011, 08:53 »
You can simply disable the "mechanical" system in the system dialog. Or use "select sets" in the set information window in combination with the mechanic variable filter to not-select mechanical sets (use "logical not" in combination with %M=1)
Additionally you can enable scanner's advanced option to mark disabled sets as unneeded.

2635
clrmame Discussion / Re: New Feature Request
« on: 28 August 2011, 15:16 »
since I'm on the road today I come back to you tomorrow.....

2636
clrmame Discussion / Re: Work In Progress
« on: 24 August 2011, 19:06 »
heheh..actually another routine used the exact same pointer arithmetic...so ...another place to fix ;)

2637
clrmame Discussion / Re: Work In Progress
« on: 24 August 2011, 12:51 »
you missed minor stuff....clipboard wasn't fully fixed after I fixed your reported one for example...actually you reported most stuff.

2638
clrmame Discussion / Re: Work In Progress
« on: 24 August 2011, 11:55 »
well...resolving was pretty fast...like 5 minutes..

I had an idea which part of the profile reader could be the cause for the fail after the debugger said something about the string class...
For the unicode build only that part had some weird LPTSTR casts here and there...so I rewrote that part and it worked...

2639
clrmame Discussion / Re: Work In Progress
« on: 24 August 2011, 10:43 »
actually I'm not sure if it was an actual bug....

debugging the lines is fine, running them is fine (on Win7 always, on WinXP always when runned from the Visual Studio)...but a standalone release creates an issue with some Windows based libs......sounds more like a compiled code issue..

anyway, I rewrote the few lines and replaced some pointer arithmetics with basic function calls and it works....case closed.

2640
clrmame Discussion / Re: Work In Progress
« on: 24 August 2011, 09:43 »
Looks like I've nailed it down...

never ever do pointer arithmetics when working with unicode :O)

Pages: 1 ... 127 128 129 130 131 [132] 133 134 135 136 137 ... 165

Page created in 0.136 seconds with 19 queries.

anything