[Coco] VCC Path to .INI

[Luis Fernández]

I was just waiting for you, I have not seen anyone else interested (besides pierce), want to be able to discuss how to do several things.

Do you have any improvement besides keeping the look?

I can do the direct extraction and pushed, but I would like to discuss if the method you use is correct, it's a bit straightforward, without asking for the AppData container

I can also use the registry, and the AppData setting

I can not use Winuser.h?, I lose VS6 compatibility?

For example, when making this change, we become more dependent on windows, since these special directories are only windows.

And I have already seen that for the keyboard configuration, (that I am doing in this mmento) there will be more dependence on windows.

Should I read the keyboard configuration, or do it manual ?, ie internal or external tables using an ini or other method, of all languages?

I wanted to put a combobox or pull down with the international keyboards to choose from, even with its very nice on-screen layout, but the best thing seems to be to read the current one.

The idea is that the scancode 1 = esc, I present the word (ESC) but in other languages may be another scancode, of course ESC is not a good example, it does not change, but if the ";" Which in Spanish is "ñ"

The problem is that I have to show every scancode as it looks, and I need the tables, and I do not want to ask a lot of windows because it makes me dependent on it
--------------------------------------------

De: Coco <coco-bounces at maltedmedia.com> En nombre de James Ross <jrosslist at outlook.com>

Enviado: miércoles, 19 de abril de 2017 06:09 p.m.
Para: CoCoList for Color Computer Enthusiasts
Asunto: Re: [Coco] VCC Path to .INI

Luis Fernández wrote:
> New modification already done, change location of the VCC.INI
> to the AppDataRoaming directory.

This is great Luis.  Just curious, are you planning on pushing your changes to your fork on github?

I’m still learning more about Git / GitHub … I want to begin using Git exclusively for my “real” work.

I think initially I should have created a new “branch” off the VCC-1.200b branch … And then each person wanting to cooperate would do the same, and then “merge” from each other’s branches.  In fact, each “logical” project should be in its own branch until it’s done and then pulled into the parent branch at which time the project branch can be deleted.

I’m experimenting on my local computer(s). I’ve learned to create the “server/client” relationship with Git -- however, that is not the terminology that is used in Git. A server repository is a “bare” one.

Anyway, Luis, you can’t go wrong by just committing your local changes and then pushing those occasionally.  Be it debug code or whatever. By adding comments to the commits, and pushing occasionally then one can follow what you are doing. We will figure out the “branches” and the proper way to do it as we go.  *If* you ware wanting to cooperate w/ what I am trying to do that is.

Of course these are just my friendly opinions on the subject matter :)

James



--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
CoCoList for Color Computer Enthusiasts - pairlist5.pair.net<https://pairlist5.pair.net/mailman/listinfo/coco>
pairlist5.pair.net
This is a list for enthusiasts of the Color Computer in all its forms, its clones, and its software. To see the collection of prior postings to the list ...