Johnny 5 only support 10 joy buttons? (fixed), but file/open not work?

[Space Fractal]

Hi Howard.

I have downloaded and have tried your Johnny 5 application.

It seen there are only joycode up to 10, and not 32. Because of this, I can not use your application, wich may been great to work with my frontend. Im using GP-Wiz49 interface, that use a game controller, and not keyboard as interface.

It would been a much finer to aviable to remap with keypress to prevent this list too been long. Otherwice, just expand the list to 32 buttons, but shrink to 4 joysticks instead (I have not seen a homecabinet with more than 4 players anyware).

Best regaards
Space Fractal

[Howard_Casto]

Read the readme.txt.  J5 supports as many joystick buttons as you want, I just didn't add them in the "keycode constants.txt" file in teh data files folder.  Add em yourself.   

[Space Fractal]

hm, ok.

There was just no info about joycode and keycode constants.txt in readme or in docs (could not find it). It would been fine if you split readme.txt about changes in a new file, and maybe move this file in the docs folder as well.

So....

[Space Fractal]

Hmm, in beta 2.5, File/Open do not work at all? All it does is... look in the screen shot.

[EDIT]
This is a floating point problem, I saw in Mameroom control config application as well. I cant manage Visual Basic have trouble to convert these strings automatic.

We use comma in EU to floats and not a dot as you does in US. This cause the bug, as you can se in the lof file.
[/EDIT]

[Howard_Casto]

Well yes, I see the problem.  Figuring out how to fix it though, might be difficult.  See the float number is generated automatically upon print out, internally upon view the number isn't turnicated.  I suppose I can manually edit the text back, but then I need to assure that none of the values stored in the file never actually need a comma. (Probably unlikely). 

In the meantime, using notepad.exe to replace all commas with decimal points should make it viewable. 

So the layouts are showing up when a game is displayed though?  Man that's wierd.

[Space Fractal]

I tried that, but even with the default layout it does not load curretly (I guess the save routine is fine), but it work when I changed my prefer language to english (includning my own, when I replaced comma with a dot).

So try to change to danish as your language (it only change formats like this)  from your windows control panel (internal languages I guess it name in english), and you would see what it does. This should been easier to fix that way, when you can see it (because it hard to blindfix it).

Maybe you can disable this feature internal in your application, so it allways use dot as float?

[EDIT]
Im didden't try with a game, because im just have created the layout (Etc not moved to arcade machine yet). Im asume the bug would been the same, because of this problem.
[/EDIT]

[Howard_Casto]

We might be screwed on this one then.  It sounds like a text services problem, which is completely beyond my control unfortunately.  It's an automatic conversion and there isn't any possible way (that I know of) in which you can manually adjust it, other than the method I just mentioned, which apparently isn't working.  Vb6 pre-dates the langauge options standards unfortunately.

What we can do is monkey with the advanced text services option in xp and see if it fixes it. 

Here's what you can try:

Go into control panel/regional and langauge settings

In the code page conversion tables in the advanced tab, make sure  "US-ASCII" and any other american-related reigons are checked.  They are checked by default on my system, but I can assume they aren't on yours as all the regions in your neck of the woods aren't checked. 

Xp is *supposed*  to use American values with American programs so this could be the cause. 


If that doesn't work in the details button of the languages tab you can try adjusting the "advanced text services" (just use the opposite value set)  Text services are supposed to just allow for speech and handwriting recognition, but they often monkey with conversions on the languages as well. 

If none of that works, I think there are tools available to run apps in a sort of compatability mode.  I don't know of any off-hand, but we should be able to find one if it comes to that.

[Space Fractal]

Visual Basic is a Microsoft language, and they should take care of it. XP is made by Microsoft, so I can not still manage, there are trouble to get this working. There MUST been a option to disable it, mostly because Im only have seen on these 2 layout applications.

My guess you should doing these to take care of this bug:
- Read allways lines in the ini files a string, regaardless it a number of not.
- If it a number, replace any comma with a dot.
- An then use a string to float converter (val# or what it name in Visual Basic). Im so hope this funtion dosen't have problems.

Remember using user32.dll (if rememeber correct) and reading ini files is NOT supported by Microsoft anymore (they prefer to use the regfile instead). You may need to make your own reader instead, instead the awful Microsoft one (and so you have a LOTS more control, what it does.

AS you see EU and USA use theier own standard, and these need to been followed. Im would not change my prefer settings  (classic theme, and danish as my language).

I hope you can fix this one, so I must wait to use it.

But I do not know you you read them back again from the ini file, it should convert them back automatic, but it seen it dosen't......

[Howard_Casto]

Did you try what I said?  Checking these options doesn't change the default language or any of that stuff in any way, it merely adds additional compatability. 

[Space Fractal]

yep, and it works (As I allready said in a eailier post, you may miss it).

But it would been better this could been fixed thougt, wich would been a more correct way. It still a bug, and it should (hopefully) being fixed in your open code (Im dosen't known Visual Basic, So I can't see what it doing).

This is why I asumed you to tried danish as language, so you could see the bug in action.

You may need to get this to been disabled to get it to work. It mayben a very sad sad bug in Visual Basic or the service you use as well? I never seen this bug in other basic language as well?

[Howard_Casto]

No you said you changed your preferred langauge to english, which isn't the same as what I suggested.


However if you have tried my suggestions without english as the default langauge and it works, with respect, then it isn't a bug and is working just at it should. 

Just as a Japanese video game won't work on a US pc without japanese langauge sets and sometimes japanese code conversions, you are going to have trouble unless your US plugins are installed. 


I know you are unfamiliar with vb, but what I've been trying to tell you is I have absolutely no control over how vb prints out really long numbers.  It isn't a ini file thing either.... if I were to just use a ascii print it would give the same number.  I can convert the value into another format, but then it gets rounded and thus the placment is far less accurate. 

Now I can manually go back after the fact and replace the "," with a "." but you said in your reply that this didn't have any effect until you turned on english as the default language, which understandably you shouldn't have to do.  Since I can't alter it manually then there really isn't any other way to fix it.  Now if you happen to run across a solution I'll be glad to add it, bt my searches haven't turned up anything.  This is exactly what those code conversion packs you can download for xp are for.  They do the heavy lifting so programmers don't have to code specific functions for each region.

Probably the only reason you've seen this on cpviewer and my app is because they are both skinnable and that is the one type of app in which really long numbers are used (percentages of the screen tend to get messy).  Only when one of these values are stored to a text file and loaded does this issue turn up because it's a printing thing.  If you are to create and use such values internally they will work just fine. 

I tried it in danish and I can replicate the error, I just can't do anything about it.  The problem appears to be that my program uses american vb controls and american controls can't handle EU style values.  Internally the numbers get read fine, but if you try to apply them to a control, even if you pass it through a variable first it fails.  This seems to be a core error as the program doesn't error out, rather it just quits.  It's quite common in any visual studio 6 langauge to have regional issues just like this.  This is why m$ no longer officially supports vs6. 

[Space Fractal]

hmm, I can just tell the control seen to been buggy, since the control didden't actuelly check wich formats it use (wich would been very prettty simple)..... (im dosen't know you use a microsoft, or a third party component). That all.

Cpviewer from http://www.cpviewer.emuchrist.org/ seen to work fine (mostly because it use integers values, not floats). But it seen, it dosen't support if I remapped some controls in some games (like pinball games).

But have a some trouble with http://www.mameroom.com/CPKD_info.asp (but I remember it works, it some time I used it)....

Maybe saving to a binary file would been better than store as text, or upgrade visual basic?

[Howard_Casto]

Ironically, to get j5 to work well I had to keep using vb6 and not upgrade to .net. 

.net offers a ton of cool new things and easier code.  Unfortunately, it also has the most useless form controls I've ever seen.  You think vb6's are bad, in .net you can't even make the background of a label transparent!  Not only that, but you can't print a form unless it's visible, and even then it's a screen grab, cursor and all, meaning I would have to re-write the entire core if I wanted to keep the "-justprint" feature.  The same issues are found on images too. What's the point of natively supporting pngs in .net if the background of the control can't be set to transparent? 

Mind you I could have easily coded the whole thing in DirectX, but I was asked to make the app as compatible as possible when I was building it and a directx version would be video card dependant and require more resources. 

I don't think binary will work either.  The problem is visual basic itself is using the EU format internally and auto converting it to EU when Danish is the default langauge.  This is why manually changing the commas to periods didn't work for you initially.  The controls on the form, however are all expecting the american format. Stranger still if I calculate a number internally(without reading it), it appears in the American format.  Makes no sense to me either, but I didn't write the thing. 

If you are able to get it running with the xp plugins installed though, then I'll consider it ok as-is. 

[headkaze]

Using GDI+ would be the way to go if you were to go with .NET, although I'd assume it would be alot of work to port everything over. GDI+ still dosn't support the PNG's alpha channel though, you can set a transparent colour key though.

The GameEx Theme Editor was written using VB.NET, and was my first major program written in .NET. It was based on an assignment I did for Graphics Programming at Uni.

Feel free to check out the source. It's pretty crap but was helpful getting started on the Theme Editor. If your gonna keep up with things you will probably have to give up VB6 and move to .NET eventually. I used to code in VB6 and now that I've moved to .NET (I actually prefer C# now) I can't stand VB6 anymore. It will probably happen to you to!

[Howard_Casto]

If your gonna keep up with things you will probably have to give up VB6 and move to .NET eventually. I used to code in VB6 and now that I've moved to .NET (I actually prefer C# now) I can't stand VB6 anymore. It will probably happen to you to!

heh I doubt it.  Right now I'm being forced to upgrade one of my helper apps to .net because it can do something that vb6 can't (which hasn't happened to me in 3 years!)  The vb6 version was very tiny and had maybe half a page of code.  I ran it through the upgrade wizard, so far the amount of code has tripled, and I still haven't gotten it completely working yet.  .net is great for programs that don't need a gui, so i might eventually switch my wrappers over to it, but the graphical interface, especially the default form controls are pure crap.  Even if they'd just fix the form controls I'd happily jump ship. But when I don't have an image control and I can't make the background of labels transparent... bah!!!

Dk is mostly direct-x, so eventually it will be ported when vista can no longer handle vb6 and everone is actually using vista.  But actually dk will be an easy port because it doesn't use any user controls.