Hi,

I'm trying to use the CCF Compiler / Decompiler (it
occured to me that this might solve my labeling problem...). I must be doing something extremely
wrong, basically, but the three .exe files in the
zip archive simply do nothing on my Win98 machine.
They just exit silently, no window opens, nothing.
Tried from the DOS command line to get the same.

What am I missing?

Thanks!
Doron

Did you also download the DLL file (CCFDLL.DLL)?

Ouch. How stupid of me. Thanks!!
It works like a charm now (and, hopefully,
will give me a way around that nasty PE2.0 bug
with labeling IR codes plus emulator crash:
insert IR codes, decompile, edit CSF to manually
add label, compile - and voila!).

Thank you
Doron

Following up on my own posting:

When I take a v2.0 CCF file, decompile it (making CSF), and then compile it again (CCF again), something funny happens to the UDB codes. The codes are still there, and they work(!), HOWEVER using PE2.0 to edit and analyze the codes reveals that their association with a vendor/device/key triplet has been lost (PE2.0 says "non-applicable" on all three).

This is a bit strange, mainly due to the fact that it still works - meaning, if I understand correctly, that the index into the DB is still intact. Yet, for some obscure reason, PE2.0 doesn't add it up to point to the original codes. This makes the resulting file "impefect", if you will (i.e. decomp/comp loses information).

Is this a compatability problem with CCFDecomp/CCFComp? Anything else?

Thanks!
Doron

YOu get the same thing if you convert a V2 CCF to 1.05 format and back again.

There are 6 bytes added to the code which are not displayed. These tell it which device, brand etc. Sounds as though the decompile is not saving these and they are being reset to zero.

Use 1.05 to create a CCF with the buttons you want, then merge this CCF into your V2 CCF.

Doron, you should let Olivier know too, so it can be fixed.

Indeed, you are right. I will. Thanks.

Strange that it would drop the FIRST few characters rather than the LAST.

Exactly my sentiments. Which is why I thought it's not just "first few bytes" but something slightly more intricate - sort of a separate atom or something. Oh well, I know practically zip about the binary structure of CCF.

Olivier has changed compiler/decompiler for V2. I suspect these extra bytes are being set to zero.

Doron, I assume you installed the most current versions. It might be possible you have the old decompiler (which is not outputing these extra bytes) but the new DLL (which knows about them).

Most current version on the files area (0.45). Still happens. If you have a different experience please let me know!

Well, I should have read the readme more carefully. It says this (brand/dev/function are lost). Some sort of V1 compatability. I wish this could be corrected though...

Indeed in the last CCFDLL.DLL, these 6 extra bytes are detected (but not decoded) and totally ignored. So, It explains easily why UDB associations are lost when using CCFCompiler/Decompiler.

Obviously, I really hope it will be possible very soon to decode these 6 extra bytes. In fact, 2 weeks ago, if I remember well, Peter Dewildt sent me an explanation of what he discovered : He was able to partially decode UDB extra bytes and found how vendor and device names were coded.

And unfortunately, for the moment, I didn't find time to make further research about that. So I still don't know how function & set are coded. May be Peter has done some more work and knows everything now.

Olivier Couvreur