Freeeee

thank you both. Christopher pointed me to an online source that works really well for me, but thanks for the URL you provide Anders. it pointed out that you CAN include short snippets of code as long as you do it in the right place and manner. Of course it has to be interpreted by the compiler. Changing to complex strings has made the compilers job much harder. Apparently it understands Kanji. Quite an accomplishment. The right place is harder to find (for me at least) in the Emb. docs. pages. And you are correct Anders, that I do not (yet) understand the basics of Modern Delphi. But I'm trying,. Thanks for the pointers. By the way, Anders,, what do you use Includes for?

Thanks Christopher Just to make sure you get this I'm using the reply to quote. the URLto Delphi Basics was REALLY helpful. Thanks again.

THANKS Christopher. That was useful. b

Thanks for your reply. And sarcasm. I found dot INC files very useful and wondered if they had been preserved. They have not. I think they would still be useful. but I can do without them. cutting and pasting works too. just a bit tedious. Apparently the memory size of an "Ap" is no longer a problem. And it's perfectly acceptable to include all sorts of code in an Ap that the Ap never uses. After all the IDE automatically includes: Winapi. Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; Just to start a new VCL project.

thanks for the answer but Unit do not provide the same funcionality Units are stand alone and will compile and execute. and require USES to tie units together. An Include file was a piece of isolated code that could not be compiled on it's own. It did 'some thing' useful. after working in Turbo pascal for several years you'd have a whole set of useful include files. Really nice for defining records too or as you mentioned for constants. So the answer is NO there are no dot-inc files for Delphi 12. Correct?

I added those to see if I could solve the problem. they were not there originally. It works from the keyboard with C.r/Lf added to each line, I sent the code for the entire program. Moving the data back and forth seems to delete lines from the memo box until there's only one left. It's possible it was a bug in 12.1 and may have been corrected. I'd still like to know if there;'s a "Reset" button for a Memo box that would let it accept data programmatically rather than the keyboard? I understand that this IS NOT the way to do this. It wasn't under MSDos and Delphi 5 either. Then you could clear (what is now the form) programmatically with a single command "CLS" in turbo Pascal. Then set up a completely new Page using indexed GotoXY (x,y) and strings in one array in a loop. complete with new tab stops at data entry points. If you worked in Assembly language you could setup the Pages in 23x80 Byte arrays in memory and just move it to the O/S screen memory. But memory was short in those days so it was 'Better' doing it the first way. I had 6 or 7 ways of displaying all of the data in various formats on a single screen one at a time. I suppose with the "visible " property on buttons, labels, and boxes It would be possible to do that now but the Form design "Form" would be impossible to read with all of the labels (etc) over top of one another. It would be possible if you did all of your page design in the text version rather than on the form design screen. You'd have to name your labels etc carefully/ But that would satisfy the one form per unit requirement. Things have changed since Delphi 5, and I'm still learning 12.

this works: // <------- LblFirstName.Caption := Memo1.lines [0]; LblMiddleName.Caption := Memo1.Lines [1]; LblLastName.Caption := Memo1.Lines [2]; each memo line ends up where expected. this doesn't work. // <------ Memo1.Lines [0] := LblFirstName.Caption; Memo1.Lines [1] := LblMiddleName.Caption; Memo1.Lines [2] := LblLastName.Caption; two buttons. 1st invokes the Memo to labels 2nd the Labels back to the memo The firstName field shows up in Memo.lines [0] Usually nothing in [1] or [2], but some times all 3 show up. Usually just [0] or [0] & [1] very sporadic. why do I do this? 1st. It gives the user a look at what the data will be when moved to a record. 2nd. the original data is still in Memo and can be corrected an moved again. 3rd it will allow the App to read an old record into Memo and correct it in the same way ti was created. Kind of "Oh! I know how this works." for the User.

steps to test it. enter first name linefeed, Second Name l/f, 3rd name. You now have 3 Tmemo lines. It';s important that the lines in the TMemo line up with the Tlabels.. button1 move the Tmemo lines to the Tlabels. examine the Name. There are errors in it. Button2 move the 3 names back to the TMemo. correct the errors Button1 move names back into Tlabels. Repeat until names are correct.

Procedure TForm1.Button1Click(Sender: TObject); begin // FROM LABELS this does not work reliabley Memo1.lines.clear; // delete old values Memo1.lines.Add(Label1.caption); Memo1.lines.Add(Label2.Caption); Memo1.lines.Add(Label3.caption); end; procedure TForm1.Button2Click(Sender: TObject); begin // FROM MEMO LINES this works Label1.caption := Memo1.lines [0]; Label2.Caption := Memo1.lines [1]; Label3.Caption := Memo1.lines [2]; end;

nope. did you try it? I just added the code the move from Tlabels to Tmemo still doesn't work first line is missing on move back. ??

thanks. that was my question. "is there a procedure/function that makes sure there are enough lines?" Nice bit of succinct code too. 🙂

Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; type TForm1 = class(TForm) Label1: TLabel; Label2: TLabel; Label3: TLabel; Button1: TButton; Button2: TButton; memo1: TMemo; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin // FROM LABELS this does not work reliabley Memo1.lines.delete (0); // will cleaning help? Memo1.Lines.Delete (1); // nope each B1 clk removed memo1.lines.Delete (2); // another line. Memo1.lines [0] := Label1.caption; Memo1.lines [1] := Label2.Caption; Memo1.lines [2] := Label3.caption; end; procedure TForm1.Button2Click(Sender: TObject); begin // FROM MEMO LINES this works Label1.caption := Memo1.lines [0]; Label2.Caption := Memo1.lines [1]; Label3.Caption := Memo1.lines [2]; end; end.

This is interesting. The move from the TMemo to the Tlabels works fine. Every time. too. Actually there are 14 lines in the TMemo in the 'real' program. The example I used was from a test program. Three seemed like enough. It's moving the same labels (all 14 of them) in the same program back into the TMemo for editing. a ?? second later?? that doesn't work. where did the TMemo lines go? Hitting the button that does the move from TLabel to TMemo several times seems to 'use up' Lines until there's only 1 left. Does moving lines To a TMemo, from the Tlabels, make the number of lines available smaller? Why? That doesn't make much sense. typing into the TNemo from the keyboard still works. is there a command to make sure the TMemo has 14 lines in it.??? I Thought from reading the description of TMemo, that the number of lines was more or less "Very" large. It says 'infinite' but that's a stretch.

Thanks again Remy. as usual, your answer are precise and lead me to a better understanding of what's available. I had just discovered string grids, last nigh. 🙂 thinking there has to be a better way for Users to input names and dates. Do you know of a resource online where I could page thru the available resources.?

Is there any way of running code at program start up. right now it looks like code only runs when you click on a control on the form. Is there any way of running code before you get to that point Example ap creates and Ini.file that records where you were at in the last time you used it. is it possible to read the ini file without having to click on something in the form when the form appears?? If so, where do you place that code? Does it need to be a procedure? Does it have to have a 'special' name?

Thanks what I needed.

type TForm1 = class(TForm) TForm2 = class(TForm) ....... private { Private declarations } public { Public declarations } end; var Form1: TForm1; Form2:TForm2; doesn't work BUT if you put the Type and Var statements + an 'end' under "private'" or "public" it does compile.

thanks The data modules are new since I last used Turbo Pascal & Delphi I'll look into it.

the reason I'm doing that is I have 3 separate but related pre-existing direct access files that have to be kept in sync with each other. I need 3 different forms in one program to do that. So rather than "Don't Do That" what do you suggest? we could to e-mail if you';d rather to keep the subject out of the forum but that seems to be contrary to the Forum concept. I'm perfectly happy to have multiple units (dot pas files) and then use the USES statement to collect them into 1 executable. I did that years ago using Turbo Pascal and Delphi version? without much of a problem. That code is corrupted or missing now. and it only ran on 16 bit DOS or WIN 3 But the files are still intact. I'm trying to update it to a 64 bit world.

so I'd replace the *.DFM with specific, named dot DFM files? by the way, that statement looks like a comment. or is it a directive like {$-} and {$+} around I/O statements? Or would I use the USE unit2, unit3, etc?? to gather the files. Is there some where I can look this stuff up in an Index?

thanks. I was coming to that conclusion. having a IDE designed around a forms design screen without allowing multiple forms seems like a bad idea. I programmed in Turbo pascal on DOS and Win3 years ago and Delphi seemed to be a better product then. much easier to use. Am I correct in that that the 2nd and other forms have to go into either the public or private sections?

I have two units (1 & 6) with associated Forms 1 is the stratup form. I want a button on that form to close form 1 and open form 6 for further input. I need to call a procedure in from 6 after the button is triggered to use a file write routine in form 6 before (or as) closing form 1 and opening form 6. How do I do this? Sounds simple but I haven't found a tutorial or book that shows the code yet. I know the code goes into the buttonclick procedure and I have found the USES clause for Form 6 but making the transfer from 1 to 6??? not yet.

thanks... very much. It worked just fine with a few minor adjustments. I used Hide on form1 because it was/is the main form and didn't need the Action on form6. It would seem like a simple thing to do but I couldn't find that bit of info any where. Do you know Cathy Henley?