for a lot of change since kol 3.00, i adviced to define a symbol like {$DEFINE KOL3.00} in KOLDEF.INC, let user conditional define code base on kol version above 3.00. like delphi version symbol, i think it is useful.

Useful, but hard to maintain, beacuse it will cause a lot of extra defines in the code. There are already close to too many conditionals, although most are transparent for the average user.

no extra job for kol, but for user of kol.

<smile> it is not just the switch, it is what the switch is supposed to do. THAT is a lot of work for Vladimir...
Every single change in version (added code, changed code) has to be prepared for the version switch. And that is a ***** lot of extra work!!

Feel free to maintain it.....
I don't think it is going to happen.

Let me explain further:
A compiler switch (like $VER185) is related to the compiler itself and also takes a lot of work, but far less than a conditional compile switch (Like $PASCAL_VERSION) - for sourcecode - that you suggest: sourcecode is not a compiler: every change has to be enclosed in the proper conditional switches: and that is a lot of work.

Stop. What is the hard work? Where?
But. I do not see any benefits nor for me neither for programmers using KOL.
First, what this define should control in KOL.pas+KOL_asm.inc+KOLadd.pas ? Nothing? And what is the reason in that case to place it in KOL.pas (or included files)?
Anyway, you can define any symbol you wish for your purposes, if you plan to control something in your code. I can advice also to use EXTERNAL_DEFINES in large or big enough projects. In that case you can place some {$IFDEF } ... {$ELSE} ... {$ENDIF} constructions in the EXTERNAL_DEFINES.inc and control used symbols more carefully.
Symbol like KOL300 or something else you certainly can define in that file to control other defines if you wish.

My Hope is Only Define Symbol in KOLDEF.INC, nothing else job for kol's ahthor. i wrote some control base on kol 2.94, it is not good work in kol 3.00, so i hope my change would work on kol 2.94 or kol 3.00 base on your deifne not by me.
becase kol's code is changed always, define a flag is only a line code for you, other work is throwed to kol's user.

Ah, now I see.

I do not mind, but for me I see no difference if the such symbol defined in the external file which you include (e.g. EXTERNAL_DEFINES.inc) or in KOLDEF.inc. Anyway you should include it into each your unit where you refere to it. And if you forget to include it, anyway it will be undefined.

if you are kol&mck component writer, the new control's end user is not yourself, it is different :)
kol&mck component writer can write code work on diffirent kol with diffirent version

Sorry, it seems I forgot to write: a symbol KOL3XX is defined now in KOLDEF.inc.

Today while updating Column Commander on the kolmck site and read my own news I did not find such info in the announce on the last version.

{$DEFINE KOL300} seems more fine, if KOL3.50 changed a lot of things, you can append {$DEFINE KOL300} after {$DEFINE KOL300}, XX seems not sure:)
thank you.

{$DEFINE KOL300} seems more fine, if KOL3.50 changed a lot of things, you can append {$DEFINE KOL350} after {$DEFINE KOL300}, XX seems not sure:)
thank you.

If a lot of things will be changed we shell add {$DEFINE KOL35X} (but not remove KOL3XX). Defining KOL300 is not correct still versions are changing often so KOL300 can mislead a bit.

agree with you:)