Freeeee

function DaysInMonth ( Mo, Yr : LongInt): LongInt; begin case Mo of 1,3,5,7,8,10,12:DaysInMonth := 31; 4,6, 9,11:DaysInMonth := 30; 2: If (Yr mod 4 = 0) and (yr mod 400 = 0) and (yr mod 100 > 0) then DaysInMonth := 29; else DaysInMonth := 28; end; end; It's based on the Gregorian calendar's rules for Leap Year. And YES I KNOW that Delphi has Date Routines that are better than anything I can write so, please spare me that critique. I want to know why the compiler rejects this with 4 errors in one Unit but accepts in a different Unit. .

TOO ALL who answered. Remy is absolutely correct. I was trying something stupid and it didn't work. I thought if I could figure out why the IDE/Compiler got stuck there I might be able figure out how to fix it. And the problem was in the dot pfm file. which are part of the 451 lines above the problem. Thanks for pointing me to those URLz , Remy. They did help. Thanks everyone. I'll refrain from stupid questions... well.... I'll Try to refrain from stupid questions in the future. I've noticed that the Format the code option gives you a kind of Ominous warning. When some one asks you "do you 'Really' want to do this?" it made me think.."hmmm .... maybe not.'

code was from ? 2000,. Worked then. There wasn't a reserved word "Result" so you used the function name at the end of the code set equal to whatever variable you were using to get the results. Function doSomething: Integer; var X : integer begin X := code to do something; doSomething := X; end.

Yes, I am running MSDos, AND Window XP And Window 10 and my game machine is a Win 11. Emulators are great, if you can remember which system your in. but I don't like side kick at all.

thanks Remy agrees that I've screwed up something higher up in the code so the compiler is confused. I'm still 're-' Learning. 🙂

Hi the function worked perfectly in Turbo Pascal when I first wrote it. then you used the name of the function to return the value. and Yes I could use Result rather than function name. but the question was why is the compiler finding these errors (that are not errors). Why did this function Pass in 2 other Units but not this one.

Is there some reason for using Non-Static as opposed to Active or Dynamic when talking about classes? What I'm understanding is any Procedure code generated from the Tform by some action (like a mouse clik) is in the TForm class. so as long as you do ALL of your coding inside one of those procedures you don't have to qualify back to the TForm. But if you call something like a WriteRecord procedure that was NOT generated by an action in./of/on the form you do have to qualify because you;ve gone outsife of the scope of the TForm class. or are the nuances ?? like hierarchy rules. Is it "You know when your outside of the class scope when you have to qualify". or is there an easier way?

thank you Remy the errors are E2023 Function needs result type at line 415 (415:10) there - is - a" : LongInt; " after the closing paren E2029 Declaration expected but '(' found at line 415 (415:22) that's the opening paren for Mo, yr: LongInt E2003 Undeclared identifier: 'Mo" at line 417 (417:11) Mo was declared in the input args E2993 Undeclared identifier: DaysInMonth at line 418(418:22) ??? It's the name of the function. I already admitted that Delphi has better date routines. and I wrote this routine in turbo pascal before Delphi. That's beside the point. I want to know WHY the compiler accepts the routine without error in at least two other UNITS earlier but NOT THIS ONE? the above errors don't mention 'duplicate function ; or anything that indicate that's true. they are all about the way it's written. Is there some major flaw in the code above the routine that confuses the compiler so badly it starts flagging errors where there are none?? By the way, Why would I need to qualify a variable on a form when it's the ONLY form in the program? example ( ABCycle.Visible ) is a E2003 - but if I put in ( Form5.ABCycle.Visible ) in the code it's accepted. And Form5 IS the only form in this particular program Same program as the DaysInMonth problem

I tried the test Unit but It recompiled without errors. and it would be the empty unit you described. one memo, 1 label 2 buttons. button 1 converts the date in the memo and moves the answer (which is days since year zero) into the label. Button two converts the days back into yyyy mm dd form and moves that back into the memo. If you used "/" as a separator there;s no change, If you used space, comma, period or letters as separators they're changed to "/" so you know it worked. ie you got back the same date. I got the idea from Microsoft. There year zero date is 01/01/1980. mine is 01/01/0000 . good in a long integer (and a 5 digit year) until 31,999/12/31. I think your right about something else going on that's confusing the compiler. The Unit it's in is quite large Over 500 lines. and there's till more code to write to get to a working program. I think what I'm going to have to do is fix the other typos and errors first and just leave this code alone hoping that eventually the compiler will accept them. I'll just comment then out to continue testing. thank for you help.

Thanks for replying. That was a good catch. I think i put that semicolon in trying to correct the errors My bad. Sorry. taking it out didn't change any of the four errors which start at the function label on line 415 interesting I can't cut and paste errors so I'm going to copy them E2023 Function needs result type at line 415 (415:10) E2029 Declaration expected but '(' found at line 415 (415:22) E2003 Undeclared identifier: 'Mo" at line 417 (417:11) E2993 Undeclared identifier: DaysInMonth at line 418(418:22) the function heading should be the identifier and I was under the impression that the arguments passed are placeholders for the real arguments as long as they are of the same type. LongInt in this case. I didn't use VAr in front of them because they shouldn't be modified. This worked fine in a Unit where the full routine of which this is a part was tested., aside for a label a memo box and two buttons it was the only code the test program. So I'm trying to determine why it works in one simple unit but not this one.

Does anyone know of a delphi pascal handbook that would explain ALL of the objects you can put on a form. I'm looking for something along the lines of ; ==================================== This is a form; here are the features you can change, Here is how to change them, This is why you might want to change them the go onto All of the VCL objects you can put on form This is an Edit box Here are all of he features about it that you can taylor. Hear is what each one of them do. Here are the reserved word you use to modify the behavior Here are 3 examples oh how you might us an Edit box. This is a Label. There are several types These are the features you can modify. Here's How to modify then. This is why you might want to modify them. Here are three non-trivail examples of how you use them. as you went along you could report "This is the same feature as on a Memo box., pg 54. It should of course, be indexed Too The book Dephi Programming for beginners by Yuriy Kalmykov was good but it only touched on a few things And no, the docs on the embarkadaro web site are not adequate UNLESS you already KNOW all of the above. I m kind of surprised that someone hasn't already written some thing like this. Even the Intel docs on programming in assmebler show each op code and what it does. and how the registers work together. SI, DI and Cx dome to mind.

I have looked at the Docs on embarcadero.com/Libraries . In earlier versions of Turbo Pascal there were functions and/or procedures we could write in a generalized form and then save them as Dot INC files . They could then be used in future programs without cutting or pasting sometimes with a forward reference but it would be named ...example " MakeDate.INC" You could include it in a new file without retyping it simply by putting 'MakeDat.INC" in the procedures section of new code. If it were in a separate folder you'd provide a path for the compiler. Does anything like that now exist in 12. ?

thanks didn't know that. but... it's about time. Some "Old" ideas are still valid and worthwhile.

glad to find someone 'about' my age. Thanks.

Yup. That's exactly what I was asking. Thanks.,! I still use the Rand Programmer's editor. Only one I've ever used that can select, cut, copy and paste Columns of text. CTRK+O would Put you into the underlying O/S . exit would put you back into the editor where you left off. habit die hard. I can easily see how I could have caused the compiler to insert those directives. Won't hurt to remove them I'm presuming. thanks again.,

thanks. that helps. you put those in for specific reasons. Does the compiler or debugger put in a whole bunch (2 or 3 screen on the editor. They just showed up on units I have been working on. I guess I cliked a button some where. 😕

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;