Dany wrote:Yes, supression of all "not used" warnings for variables defined in the Defs file, the same principle I use in my "RamSize" tool.

Precisely. It ain't rocket science but it does make a better compiler...

var ch : char; (...) ch := adc_rd div 1000; // prepare value for diplay Lcd_Chr(2, 9, 48+ch); // write ASCII at 2nd row, 9th column (...) ch := (adc_rd div 100) mod 10; Lcd_Chr_CP(48+ch); ch := (adc_rd div 10) mod 10; Lcd_Chr_CP(48+ch); Please, please don't encourage this. The result of an arithmet...

I am aware that pointers to routines are already implemented, I uses them extensively Ah, apologies. I should have realised that of all people, with your prodigious and incredibly useful code contributions, you would have already been there! :D (and tips hat) Otherwise (now I see better what you me...

'nil' is an integral part of standard pascal and it really should be implemented properly.

Seconded (and thirded, fourthed etc.) - please implement this properly, along with an initialization section . Borland have pretty much set the standard here so it's either open for improvement or, for immediate compatibility and general user satisfaction - it's surely worthwhile implementing the wh...

Late comment I know - but that's not correct about this issue being a Standard Pascal restriction. Chr() is simply a function which returns a character and as such it should accept a const, var, pointer etc. like any other function would. Niklaus Wirth (hey - remember him ? :lol: ) states in his Jul...

Heh. Yes - it's er, "a bit messy", isn't it? Not so much a workaround as a stroll through a war zone... SizeOf cannot be applied to functions. Statistics seems to be the only source of such info. Yep, I knew SizeOf couldn't be used - blast! :lol: <sigh> A GUI definitely has its place but it's a sad ...

This can already be done - at least it can in 3.20, anyway. But - you need to make the variable a pointer to type tProc, as in: type tProc=procedure; var MyProc:^tProc; begin MyProc:=@SomeProcedure; // assign the address of SomeProcedure MyProc^ // execute it through MyProc end. Be careful though - ...

the implemented protection may be easily overcome. I'm curious about the workaround you were given - could it be this: Not quite, although your example is extremely interesting and useful to know about. At the very least it retains the ability of the compiler to handle the code's resource allocatio...

Have a look at the button library and examples provided with the compiler?

Or better still: make it available?
It's not like the code doesn't already exist if it's currently possible in ME's 'C' compiler.

Fortunately, it's not, though it's a rather ornamental than practical feature (for me, that is). The idea is that on a mouse click on such comment one may open a file or a web page. Or a JPG picture may be shown while cursor passes over active comment. It could probably be a great teaching aid, or ...

For those of us used to our source being undiluted and plain text-commented ASCII - can someone please give a quick summary of what an Active Comment is? I had a brief (and nasty) reminder of that damned paperclip in MS Office, hopping about like a demented idiot... surely it's not just "dancing com...

I'm not sure why you're trying to get the address of a variable by referencing its source name - which only exists in the source code, in the simplest sense, or at least in the way you're trying to do it. You're aware that SomeVar:=@Byte1 just gives you a pointer in SomeVar to Byte1 without any fuss...

slavisa.zlatanovic wrote:Please, send me your full project.

Ah... problem - it's for a client so not really all mine to give.
I'll strip it down to the absolute basics that still show the problem and get back to you.

Edit:
Done - a zip file is on its way to you.
Many thanks.