Spørg om man vil gemme ved luk

Du skal selvfølgelig ha' en Boolean som du sørger for er [true] hvis dokumentet er blevet ændret (som rigtige editorer gør).

Følgende eksempel viser hvordan det kan gøres:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
const
  documentChanged = true;
begin
  if documentChanged and (MessageDlg('Vil du gemme ændringerne i [documentnavn]', mtConfirmation, [mbYes, mbNo], 0) = mrYes) then
    ShowMessage('Indsæt koden for at gemme her!');
end;

brug hellere event OnCloseQuery, og svar tilbage med CanClose

Som dkn siger, brug OnCloseQuery, så har du mulighed for at anullere ved at sætte CanClose til false.

OG (det afhænger så af om complete-boolean-eval er sat eller ej):
if documentChanged then
  if messageDlg('Vil du gemme ændringerne?',mtConfrimation,[mbyes,mbno],0)=mryes then doGem; //doGem er så en procedure der gemmer.

Ellers kommer spørgsmålet op selvom ingen ændringer.

Undskyld jeg spør uden helt at have detaillerne klar men - jeg går ud fra det er en MDI-applikation du har ? og jeg er ikke helt klar på hvad slags editorfelt du bruger, men er det en RichEdit ?.Og hvis jeg forstår dit spørgsmål skal programmet faktisk spørge om du vil gemme (når du lukker) hvad enten du har ændret i dokumentet eller ej ?.Så kunne måske en alm. Clickbutton-metode for 'filesave' bruges, hvis man putter noget 'on Exit' eller hvad ved jeg ind i stedet for.Altså en modificering af denne proc.:

procedure TForm3.Button2Click(Sender: TObject);
begin
If Form3.Caption='Unavngivent dokument' then
              SaveDialog1.Filename:='' //Hvis der er tale om et nyt dok

          Else    //tilskrives fildialogen et tomt filnavn
              Savedialog1.filename:=Form3.caption; //ellers det oprind
IF Savedialog1.execute then //Hvis brugeren klikker gem

Richedit1.lines.Savetofile(SaveDialog1.Filename);

end;


  ???

janbb>> For det første er det aldrig en god idé at spørge på [et eller andet]='en streng', da fejlmarginen er alt for stor. Så er boolean-metoden (som blev foreslået) et bedre valg. Man lagrer selvfølgelig filnavnet i en streng (evt. som del af en mere komplekst data-struktur), til når man igen gemmer dokumentet, men at bruge TForm.Caption er ikke en pæn måde at gøre det på.

dkn, razersedge>> Hmm, jeg kendte ikke lige den med OnCloseQuery (altid rart at lære noget nyt). Hovedet idéen i mit indlæg var nu heller hvilken event man benytter, men blot brugen af MessageDlg.

nop>> !?

Ok forklare lidt bedre..
Aner ikke hvad applikation det er, men jeg bruger richedit og det er sådan hvis man har ændret det pågældende dokument så skal den spørg om man vil gemme..

Ved brug af alle forslag (indtil videre), bliver det vist noget i retning af:

var
  documentChanged: boolean; // True hvis du dokumentet er blevet ændret
  documentPath: String;    // Indholder stien (hvis dokumentet blev åbnet)

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  if documentChanged and (MessageDlg('Vil du gemme ændringerne i [documentnavn]', mtConfirmation, [mbYes, mbNo], 0) = mrYes) then begin
    SaveDialog1.FileName:=documentPath;
    if SaveDialog1.Execute then begin
      richedit1.Lines.SaveToFile(SaveDialog1.Filename);
      canclose:=true;
    end else
      canclose:=false;
  end else
    canclose:=true;
end;

hvor skal jeg smide det ind henne ?

Præcist samme sted som ovenfor. I din forms OnCloseQuery event.

jamen jeg mener hvor i dokumnetet (mit projekt) skal jeg ligge det ?

bare nederst før end. eller?

En MDI-applikation er sådan ee, hvor der øvers er anvendt den klassiske menumetode, der giver MDI-Childs, der 'stjæler' nogen af de i windows indbyggede metoder mht lukning af vinduer, opsplitning af vinduer osv.
Såvidt jeg ved giver det en automatisk registrering af når vinduerne lukkes og det kan så bruges til at der i givet fald 'skal ske noget' - alts f.x. 'Canclose', som apbdk så flot har brygget sammen til os.

Det er nu ikke mit indtryk at det drejer sig om en MDI-applikation, men hvis du vil ser hvordan det virker, findes der et eksempel på en editor (MDI) under Delphi's eksempler. Jeg mener biblioteket er noget i retning af:

[delphi dir]\Demos\Doc\TextEdit

Mht "complete boolean evaluate" kan den findes i project>options>fane compiler gruppe "syntax options" anden linje (delphi 6).
Og den vil kunne bruges til at sørge for at hvis en boolsk udtryk giver falskt før det er evalueret færdigt så udføres resten af udtryk ikke.
Fx har man en tabel t[1..10] som man ønsker at slå op i vha af et index "i" og teste om =0, men "i" men i kan godt være udenfor 1..10 og det tester man så for:
if (i>=1) and (i<=10) and (t[i]=0) then goto doSomething;

Det er jo ikke ok hvis hele udtrykket evalueres igennem når "i" fx er 200, så vil programmet forsøge at slå t[200] op og det duer ikke !
Derfor har nogle, og jeg synes at det er dårlig programmerings-etik, opfundet at compileren tester og hopper ud af udtryk med resultat falsket hvis den kan (dvs før et and), man kunne sige at det er en overflødig option fordi en optimering af et udtryk med and i, kan sætte disse jmp's ind, men at det er gjort til en option indviterer til sådanne ting som vist i mit eksempel.
Derfor vil JEG altid lave ovenstående som:

if (i>=1) and (i<=10) then
  if t[i]=0 then goto doSomething;

Er det forståeligt?
venlig hilsen nop.

Du mener altså at det skal gøres sådan, fordi det er dårlig programmerings-etik IKKE at evaluere hele udtrykket, hvis en af komponenterne er false?

Det har ikke så meget at gøre med om hele udtrykket bliver evalueret men om at det 1: ikke er pascal, 2: koden bliver ulæselig hvis man ikke samtidig kan se hvad options er sat til.
Under optimering af kompilerens kode vil der helt klart blive sat en test/jump (nok jz $+xxxx) ind i maskin koden alligevel og det er jo godt ! Men det er et højniveau sprog vi snakker om og JEG synes at det er uhørt at benytte sig af disse tricks. Det bliver jo pludslig meget afgørende i hvilken rækkefølge at udtrykket skrives i, og det kan faktisk gøre optimerens opgave lidt mere vanskelig og dermed bliver koden måske osse langsomere.

Jeg kan godt se at det du siger med rækkefølgen (HVIS den var omvendt) ville foresage at ja/nej-dialogen først popper op og spørger, hvorefter udtrykker alligevel evaluerer til false p.g.a. documentChanged (hvis false). Men som rækkefølgen står i mit indlæg, kan jeg altså ikke se hvordan det kan gå galt!? (og at der derfor er noget i vejen med koden)

Nej den er ikke omvendt og programmet ville virke.
Men det stammer nok fra typen med if (i>1) and t[i]=1234 then ....
Hvor jeg synes at man skal passe på (aht index fejl) men ok kald mig bare forstokket - jeg har det da meget godt !
Nu skal jeg jo ikke spamme supernewbie's udmærkede spørgsmål. Tak for mig!

det fatter jeg ikke en skid af :D