--------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECI00004 Date: 08/13/97 From: GARY WEINFURTHER Time: 08:30am \/To: JUD MCCRANIE (Read 0 times) Subj: OBJECT INSP-> SOURCE CODE Jud McCranie mentioned this to All: JM> If you enter properties or events into the Object Inspector, is JM> there any easy way to then have D3 write those into the source JM> code? What do you mean? Please be more specific. ...Gary --- GoldED 2.41 * Origin: The Flying Circus BBS. (1:2410/905) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECI00005 Date: 08/13/97 From: JUD MCCRANIE Time: 10:37pm \/To: GARY WEINFURTHER (Read 0 times) Subj: RE: OBJECT INSP-> SOURCE JM>> If you enter properties or events into the Object Inspector, is JM>> there any easy way to then have D3 write those into the source JM>> code? GW> What do you mean? Please be more specific. An example would be clearer. I had a subroutine called InitData that I put in the OnShow event in the Object Inspector (OI). That was working OK. But then later in the development process I had another subroutine that I wanted to call right after the call to InitData. But there is no call to InitData in the source code - only the reference to it in the form's OnShow event in the OI. So you have to remove the reference to InitData in the OI, double click on the field, and then put the call to InitData in the source code, and add the call to the new subroutine. It would be nice if there was a way to make Delphi move the call to your subroutine to the source code, rather than you having to remove it in the OI, double click, and add it manually. It would also be nice if the properties could be done the same way - enter them into the OI, but then have them written into the source code file. I suppose that perhaps a reason this isn't implemented is due to the "two-way" nature. ------------------------ On a bigger scale, I'm wondering if it is better to do things in the OI or in the source file. It is easier to do it in the OI to begin with, but then as the project grows, it seems that it would be easier to have events written in the source code (so you can make modifications and debug easier.) Properties could probably be left in the OI to use the 2-way stuff. Jud McCranie jud.mccranie@camcat.com ... The ease of Pascal with the power of Pascal. * Silver Xpress V4.3 SW20178 * Origin: Riverdale, Ga (1:133/9024) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00000 Date: 08/14/97 From: STEVE ROGERS Time: 07:36am \/To: JUD MCCRANIE (Read 0 times) Subj: RE: SCREEN RESOLUTIONS JM> FP> You have to design your program for the standard resolution (640x480) JM>Well, what is the "standard" resolution? I don't know anyone >that uses 640x480 - all use 800x600 or higher normally. JM>What resolution do most people use? I always consider 640x480 to be the lowest common denominator. If a program is visible (i.e.: on the screen) at 640x480 it will work OK at higher res. I work with several folks who use 640x480, esp. some of our notebook users. JM> FP> and handle the Resize event then resize everything on the window. JM>Couldn't Delphi be designed to handle that for us? It sure seems like it could. When you think about it it doesn't make sense that the programmer has to worry about it. --- PCBoard (R) v15.3/M 5 * Origin: Riverdale, Ga (1:133/9024) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00001 Date: 08/07/97 From: NATHAN MALYON Time: 05:11pm \/To: DAVID MASON (Read 0 times) Subj: Re: Modal MDI child form -=> Quoting David Mason to Martin Maat <=- DM>> Can anyone tell me how to make a modal MDI child form in DM>> Delphi 2? MM> No. Because there is no point. Not only that, an MDI child is by MM> definition _not_ modal. why dont you try using a percentage of the Height and width varibles and use a normal form that adjusts size, but as MM said an MDI child is DESIGNED to be non-modal, because it was DESIGNED to Use multiple forms at the same time anyhow cya ... Lottery: a tax on those who don't understand probability. ___ Blue Wave/QWK v2.12 --- Maximus 3.01 * Origin: The BEAST (3:640/245) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00002 Date: 08/07/97 From: NATHAN MALYON Time: 06:09pm \/To: TING-CHIAO CHU (Read 0 times) Subj: Re: READ A TEXT FILE -=> Quoting Ting-chiao Chu to Jud Mccranie <=- TC> Hallo Jud, TC> On 26-07-97 at 13:43:00 you wrote to Ryan Potts: JM> I couldn't get it to work using "text". It wouldn't compile. JM> When I changed to TextFile (and AssignFile, etc) it worked. The JM> manual says that Text and TextFile are the same, but when I JM> changed TextFile back to Text it wouldn't compile. TC> Use: System.Text, System.Assign and System.Close. i think its talking about when your using a CRT Window. Because that's the only time it works for me cya ... "My God, man. We've become a tourist attraction" - Londo Molari ___ Blue Wave/QWK v2.12 --- Maximus 3.01 * Origin: The BEAST (3:640/245) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00003 Date: 08/13/97 From: PETER LOUWEN Time: 09:15pm \/To: STEVEN READ (Read 0 times) Subj: Re: Cardinal -=> Quoting Steven Read to Martin Maat <=- SR> I don't have a manual on TP 4.0, but I've seen 4.0 code that used a SR> variable called comp, so I doubt that is was defined at that time. It was, but you *had* to have a coprocessor - the emulation library was introduced in v 5.0. Peter ... Would that reason were as contagious as emotion. --- EBO-BBS Diemen - NL * Origin: EBO-BBS Diemen (http://www.worldonline.nl/~biginski) (2:280/901) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00004 Date: 08/13/97 From: DIK COATES Time: 09:10pm \/To: BRYAN SMITH (Read 0 times) Subj: Smooth Scrolling. >>>> QUOTING Bryan Smith to All <<<< BS> then blit portions of it onto the visible screen canvas at regular BS> intervals to get the smooth scrolling. BS> All suggestions are welcome. Just sorta gettin' my feet wet... and maybe tinker with Delphi. I've done smooth scrolling in BASIC... will see if I can dig up the source... likely stashed on one of my HD's sitting in a box... DOS based and not 'doze based... It's a matter of setting up a buffer space and then toolin with the CRTC registers... There's a pretty good outline of the procedure in Ferraro's book... "Programmer's Guide to the EGA and VGA Cards"... little dated, but not half a bad book... Regards Dik ... Santa Cube - Yes, there is a Borg ___ Blue Wave/QWK v2.12 --- Shotgun v2.00/Gold+ * Origin: On-Site Consulting Support BBS - Shotgun Alpha 2.0 (1:253/234) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00005 Date: 08/14/97 From: GARY WEINFURTHER Time: 08:15am \/To: MARTIN MAAT (Read 0 times) Subj: Delphi 3 blues Martin Maat mentioned this to Gary Weinfurther: MM> In a clean environment I do not have any more trouble than my fellow MM> programmers (only the occasional access violation when closing Delphi nd MM> the internal error on the first compile). Make sure all the compiler checking is on (range checking, stack checking, etc.). Get Memory Sleuth from TurboPower Software or NuMega BoundsChecker to help identify leaks and overwrites. MM> The trouble is, we have this MM> battery of components which all need each other. You use one, you need all MM> others, or your source won't compile. I know, it shouldn't be like that. Yes, the idea behind components is to make them self-sufficient. That helps to identify and prevent problems such as those you are now facing. The way to interface separate components is through the use of component events. ...Gary --- GoldED 2.41 * Origin: The Flying Circus BBS, Farmington Hills, MI, USA. (1:2410/905) --------------- FIDO MESSAGE AREA==> TOPIC: 269 DELPHI Ref: ECJ00006 Date: 08/14/97 From: GARY WEINFURTHER Time: 08:22am \/To: JUD MCCRANIE (Read 0 times) Subj: OBJECT INSP-> SOURCE Jud McCranie mentioned this to Gary Weinfurther: JM> It would be nice if there was a way to make Delphi JM> move the call to your subroutine to the source code, rather than JM> you having to remove it in the OI, double click, and add it JM> manually. Event handlers that are entered via the Object Inspector *are* in the source code. It's only the assignments of those to events that are kept in the form file. You can easily set those yourself in code: Edit1.OnKeyPress := MyKeyPressEvent; But why would you want to do this all the time? It's nice to have the flexibility to do it in code if you need to, and not if you don't. ...Gary --- GoldED 2.41 * Origin: The Flying Circus BBS, Farmington Hills, MI, USA. (1:2410/905)