New GB version coming... feature requests, anyone?

[K.C.]

With gb13b20100221.zip everything works as expected.
The problem was introduced in gb13b20100226.zip.
Did the following tests:

• On a clean XP PC, copied GB1.2 and did overwrite it with gb13b20100221.zip. No problems starting the frontend, dll's registered successfully (checked by searching registry, 3 dll's found after starting frontend)
• On a clean XP PC, copied GB1.2 and did overwrite it with gb13b20100226.zip. Gamebase did not start, none of the 3 dll's found in registry.
• Registered gemus.dll manually. Registration completed successfully, but the other 2 did not autoregister. I had to register all 3 dll's manually before I could start the frontend.
• On a clean XP PC, copied GB1.2 and did overwrite it with gb13b20100221.zip. Started the frontend (same as first test), closed the frontend and did overwrite it with gb13b20100226.zip.
  Frontend did not start, but only re-registering gemus.dll was enough to start it without problems.

[Jimbo]

Thanks again.

Seems, as you suggested, that the auto-registering code is not registering the dlls if there's already a registered version (even though it may not be the correct version). I'll take a look tonight - maybe the fix will be to just always register the dlls, regardless if they are already registered. I've not looked into Brataccas' code, but I'm assuming/hoping this should be quite a simple change.

Have you come across any other problems with the beta?

[hardmanm]

Thanks for the update, i manged to get it working by re-registering the DLLs. It looks good, apart from the games title being to the left, i liked it better centered.

[Jimbo]

hi

That's the trade-off you get for having the game name and prequel/sequel icons visible when the details tabs are hidden. If I place the name in the middle, the longer game names overlap the icons.

[Jimbo]

Something very weird is going on.

When the DLLs are unregistered, v1.3 will not run. I can't change any code in v1.3 to fix this because it isn't even getting to run any of my code (even the auto-dll-register code). When GB is compiled, it is "linked" to those DLLs, so I can only assume that because they can't be found (by the VB runtimes??) as v1.3 starts up, it fails and quits before it runs any code. How this worked before the latest beta I'm not sure, because nothing that could affect it has changed since then. I've checked the CLSIDs and they are the same as the previous versions. So right now I'm stumped as to how to fix it.

If I unregister the dlls with regsvr32.exe, then run GB, it fails. If I then re-register them with regsvr32.exe, it works again. So it would seem GB is "linked" correctly to those DLLs, and runs as long as they are pre-registered with regsvr32.

Running through my head right now is a workaround where I create a new exe (linked to NO dlls), lets call it "GameBaseRegister.exe" that will silently call regsvr32.exe on each dll, then launch GameBase.exe. Crap, I know. But it should work 100% of the time. It means if you want to run GB from removable media, you'll have to run GameBaseRegister.exe instead of GameBase.exe

[K.C.]

First I have to say I love the new interface for editing key=value pairs.

I'm experimenting a bit with it and have a few comments on it:

• Key=value pairs seem to be case-sensitive. Removing a k=v pair (last option) "setting1=1" doesn't remove "Setting1=1"
  key=value pairs are case-insensitive at all other places in the frontend.
• The new key=value pair screen is quite powerful, but not very intuitive.
  Pressing F2 displays a text box with the k=v pair for the currently selected game.
  If you want to change/add/delete k=v pairs for all games in the current view, you first have to delete all k=v pairs for the currently selected game.
  The fields are not deleted if you choose UPDATE, ADD or REMOVE, but the interface is not clear about that.
  Better solution would be adding 2 radio buttons above the text box, something like "Edit k=v pairs for this game" and "Edit k=v pairs for all games in current view".
  When the second option is selected, the radio buttons below the text box (ADD, UPDATE, REMOVE) become selectable and the textbox will be empty.
  With the first radio button selected, the k=v pairs for the current game are shown in the text box and the radio buttons below the text box will be greyed out.
• Option to select all text with Ctrl+A in k=v pair text box would be welcome. (btw Ctrl+A in GEMUS script works, but gives a 'ding' sound like something invalid is selected).

I will report back here when I find out more.
Thanks again for the update!

[K.C.]

Results of some additional testing with the dll registering problems:

When it doesn't work, I hear 2 times a 'ding' sound. Seems that most of the time 2 things go wrong.
Sometimes I hear 1 'ding', but I'm not sure if it is only one, or that the Remote Desktop connection I use ATM 'forgets' to play one sound.

When I unregister all 3 DLL's, Gamebase doesn't start.
To get it work, I only need to register gemus.dll, the other 2 seem to autoregister when gemus.dll is already registered.
Tested this also on a clean XP PC. Also, if I register gemus.dll before I start Gamebase for the first time, it starts without problems.
This reduces the possible sources of the problem back to everything that is related to gemus.dll
Gemus.dll seems to have problems with autoregistering.

Since the problems were introduced in the Feb26 version, there is a big chance that it can be eliminated to one or more of these new features:

- now using the new custom database names in the startup database-selector window, and the GameBase menu
- added status bar box in bottom right showing the id of the currently selected game
- moved game name and icons out of details tabs, so they still show when the tabs are hidden
- Updated per-game "key=value" editor (F2 window) to manage kvsets and batch-update key=values for all games in the current view
- Can now (officially) put comment lines where you enter key=value pairs (lines starting with ; are comments)
- Added GEMUS function Show_KV() (show's the key=value pairs applicable to the running GEMUS script)

IMO these ones have the biggest chance of being problematic:
- key=value (F2 window) update: I think this uses gemus.dll intensively.
- Show_KV() function: Also must use gemus.dll
- Use of custom database names. It is the very first thing Gamebase has to do for showing the Gamebase Selector window. The error occurs before the Gamebase window is displayed.

Maybe temporary disabling/remarking/deleting the new code for these features could track were it goes wrong.

Also, because I hear 2 sounds as if something goes wrong, isn't there some debug mode that displays error messages etc. somewhere in VB?
Maybe you could add some waits for keypresses in the first part of the code to determine what exactly generates the 2 sounds.

Sorry if I'm talking nonsense, I just try to help you track the cause of the problems without any VB programming experience.

[Brataccas]

Oh, I still remember fighting that DLL registration - if you need any help figuring out the self-registration code, let me know. Make sure the path didn't get switched out at some point, which would cause the registration to fail.

[Jimbo]

Thanks for your help guys.

Brataccas, I'm not sure its the registration code at all, because when GB fails its not even getting to that code (no debug msgbox's are being shown - but I guess the OS could be supressing display of them, and that's what the "dings" are that K.C. mentioned). I think it might problem with Gemus.dll the last time I compiled it, even though there were no build errors and it's still got the same clsid (binary compatible with the previous versions). What do you mean when you say "Make sure the path didn't get switched out at some point"?

The other question I have is that the registration code uses the dll names all in lower case. I know Windows filenames are case insensitive, so wondered if that was the reason. I'm probably barking up the wrong tree here but thought I'd ask (changing it to the proper case of the files didn't fix the problem anyway).

I have a diff of the Gemus code before and after the problem arose, so my next step is to revert back to the older version, and re-implement (copy) the newer code back in, then re-compile and hope the problem magically goes away.

If it doesn't I'm pretty stumped as to what to try next. I've already recompiled every dll in the correct order to no avail, so I may have to go for the backup plan of implementing a new EXE called GBRegRun.exe that silently auto-registers the DLLs using regsvr32 then runs GameBase. That would need to be used only when running GB from removable media.

[K.C.]

When pressing F2, I always see the last KVSet I've opened. This setting is saved in the registry, so even after restarting the frontend I return to the last KVSet.
IMO it would be better to show the Global KVSet every time F2 is pressed.
This will avoid accidentally add k=v pairs in the wrong KVSet.

[Jimbo]

I can default it to <GLOBAL> no probs.

The reasoning behind saving it was that if you wanted to edit the keys for a lot of games, using a specific kvset as a reference, its a bit easier than having to select that kvset each time.

[K.C.]

New beta:
- Added GEMUS function Show_KV() (show's the key=value pairs applicable to the running GEMUS script)

Nice feature. Can this be implemented also without the need to start the game/use GEMUS?
Possible options:

• Define a key combination (Alt+F2?) that launches the key=value pairs for the currently selected game.
• Add a button in the F2 window that displays the key=value pairs for the currently selected game.
• Display the key=value pairs 'live' in a non-editable text box somewhere in the F2 window (for example split the left text box in 2 parts: the upper text box for entering k=v pairs, the lower text box for k=v results).

Reason: Most of the time I would like to view the results for a certain game without starting it in an emulator.

[Jimbo]

The kv's are tightly integrated into gemus, and the environment vars are currently only replaced in the values when the game runs.

I should be able to break this code out though, so I'll see what I can do. If tht's the case, I definitely prefer your 3rd option.

[Jimbo]

I've re-"engineered" the Gemus code from a previous version (before the problems), compiling along the way, and its still not working. Same registration problem. I don't know what's going on, so for the moment, I'm going to Plan B (because I can't waste any more evenings on this), which is to make another EXE to register and run the dlls, to be used when running GB from portable media.

[Jimbo]

GBRegRun.exe

http://www.leesti.com/gbregrun.zip

The ini file is self explanatory.

This is plan B (which is looking increasingly likely) if I can't get the auto-registration working.