Delphi 64-bit. Hvad med TMessage?

Kan du ikke se det ved at bruge sizeof: n:=sizeOf(WPARAM)

mbsnet: Det kan jeg selvfølgelig men hvis nu jeg valgte at bruge både WParam og LParam og de var uændrede i 64-bit, mens objektet var 64 bit, så fik jeg et problem.

Jeg kan godt lide ideen med at sende et objekt via en message, men er samtidig bange for det er en tand for hacket og, at det vil give problemer ved konvertering til 64-bit.

Jeg tror jeg laver det og så smækker jeg en assert på så det bliver fanget: assert(sizeof(TMessage) = 16)

Jeg lukker den her, læg et svar.

ok.

Hvis der kun er op til 16bit eller 32bit antal objekter kan objekterne (måske) puttes i en array eller liste, og så sende id'et i meddelelsen som word eller longword i stedet ?

Mht til assert ville jeg nok have brugt:
if sizeof(TMessage)<>16 then exit; for at undgå undtagelsen, men nok mere en smagssag :-)

//mbs

Du kan også kaste et blik på LazarusPascal den kan nemli compile til 64 bit, så måske du kan blive klogere :-)

mbsnet: Det er helt på sin plads her med en assert. Hvis jeg skifter til 64-bit ville din kode bare exitte og jeg skulle igang med at debugge, mens min version ville brokke sig øjeblikkeligt, og endda angive linje og den slags. Asserts er guld værd!

martin: Tak, jeg vil se hvad de har gjort.

ja det var også derfor jeg skrev "smagssag" :) undgår personligt undtagelser med mindre der er konkret brug for dem (server komponenter osv) vil hellere lave indviduelle funktioner som returnerer negativt hvis fejl

Ja, det så jeg, men mener ikke det er en smagssag. Det er forkert procedure at undertrykke fejl af den slags. Testet kode som skal rettes fordi udviklingsplatformen ændrer sig skal opdages ASAP. Her er assert en aktiv prekondition, samt en stor hjælp under udviklingen.

I øvrigt kan man slå asserts fra i versioner man sender kunderne, men så får man exceptions i stedet, så det gør jeg aldrig. Men det ved du sikkert man kan.

Jeg tager det ikke så tungt med exceptions hos kunderne, fordi fejlene fanges af Madshi, som med en simpel dialog sender mig fejlrapporter. Kunden kan vælge at fortsætte programmet som jeg altid prøver at sikre mig kan køre videre.

Bedre endnu havde det været, om prekonditionering kunne laves på oversættelsestidspunktet. En "Hvis oversætteren fejler et angivet udtryk, så afbryd"-validering. Det findes vist ikke.

Jeg tror vi er enige langt hen af vejen.
Min opfattelse er at assert() laver exception hvis "false" input (kan godt være forkert)

Det jeg er kritisk overfor, er exceptions generelt.
Ihvertfald i sammenhæng med appikationer.

Har efterhånden omskrevet halvdelen af ide'et, for at undgå exceptions,
eftersom "alt" jo er direkte baseret på exceptions, indy osv.
Synes man sagtens kan lave smartere fejlhåndtering, blot ved
at returnere false (eller en fejlkode, evt som byte/word),- og i kristiske situationer (fejlfinde), så
bruge en anden logfunktion baseret på en database/tabel

Kan godt se exceptions som en god ting i mange situationer, også
fordi man ofte er nødt til at bruge dem. Eksempelvis i et ASP server-
komponent, hvor exception-fejlen også bruges af asp/server siden.

Hvis man laver en funktion (eks: "clear" eller "loadFile") så synes jeg
det er bedre den returner negativt uanset hvilken fejl, og så rutinen selv
logfører fejlen uden at bruge exceptions.

Så mener ikke nødvendigvis det er forkert procedure, men to måder at gøre
det på, og begge måder har fordele og ulemper

Med exceptions er håndteres fejl af platform (som jeg anser for en ulempe)
Synes aldrig der har været andet end bøvl med det:
Tråde der holder op med at virke efter exceptions
Bitmaps der mister sit handle efter exceptions
Exceptions der bliver ved med at skabe popups ved lukning af program med fejl
osv...

Jeg bruger mest exceptions, men det hænger også sammen med mit konsekvente brug af try-finally. Hvis der sker fejl i eks. LoadFromFile skal fejlmeddelelsen føres fra unitten til formen så cursor kan blive crDefault og meddelelsen blive vist. Jeg ved koden rydder op undervejs.

Jeg bruger naturligvis også flag fra tid til anden, men ulempen er afgjort, hvis returflag ignoreres. Med compilerflaget {$x+} er Delphi ligeglad om en funktions returværdi håndteres, eks:
 
kontra
 
Sidstnævnte kører videre og kan være svær at debugge. Hjælpen skriver at den burde slås fra. Hvorfor er den så aktiveret som standard? Må prøve det i mit program.

Assert raiser EAssertionFailed som nedarver fra EException. Den er en hjælp til udvikleren, ikke noget brugerne nødvendigvis bør udsættes for. Laver jeg en procedure hvor der forudsættes ting, så kommer der en assert til. Den rapporterer om fejlbrug prompte og den fortæller mine kolleger, at bruger de proceduren, så er der noget der skal være opfyldt. Jeg synes den er smart.

... men der er jo fordele og ulemper. Øhh. Jeg kan egentlig ikke finde nogen ulemper :-)

(den der Arduino ser smart ud)

ja, kan godt se hvor du vil hen med exceptions.
Jeg vil forsøge at fokusere mere på Assert under kodning...

Arduino, ja det er en fin lille en. Den er her i forskellige udgaver:
http://www.electrozone.dk/microcontrollers.html

Har lavet noget styring til den med Delphi,
(comport forbindelse hvor der overføres bytes frem og tilbage)
...men skal have lavet en ny, for den har nogle problemer med tabte bytes.
Tror det er samme fejl jeg møder andre gange: http://www.eksperten.dk/spm/865640
Men mangler at kigge nærmere på critalsection, om det måske kunne være løsningen
Ellers har jeg tænkt på at lave noget checksum kontrol på det sendte data

Men arduino kan bruges til lidt af hvert, hvis man vil tænde noget med sin pc,
dreje en motor, eller få inputs fra alverdens sensorer/lign.
Enten uploader man koden til den, ellers kan man også styre den direkte via usb-kabel

... eller lave en rytmeboks eller metronom. Dit led-show var sjovt.

ja. er det lpt dimsen du mener :)