HI, That might have worked. Someone else suggested something similar. I tried to use inheritance to create a second form derived from the first. Caused all sorts of problems. Not sure why.
Final solution was to load the .dfm of each form of the smaller screen version into Codewright as a text file. Did block replacements on the various words and symbols to create pascal syntax and also remove anything not relevant. Then for the GlobalMajic ActiveX controls I assigned a default to .value before I changed the top, left, height and width settings. Without assigning to .value the objects ignored the position and size values. I cut and pasted that new code into a function in each forms create and I now have a system with a simple $IFDEF that can run on the two size LCDs. All forms and dialogs and status boxes are the correct size. Thanks for everyone's feedback. John Dammeyer > > How about "visual form inheritance"? > It is in fact a nice way to get three pas+dfm pairs when you > only want one > but it will aloow you to code all the business logic in one > pas and have > design variations in the other two files. > > It works like this: > > 1) Create your "base line" PAS+DFM (PlotScreenBase) > 2) Code everything you need to code in the PlotScreenBase.pas and > PlotScreenBase.dfm > 3) When you're done do File -> New -> YourAppName -> > PlotScreenBase and save > as PlotScreenBaseSmall > 4) Repeat [3] and save as PlotScreenBaseLarge > > Pros: You only need to code once. You kind of design only > once. You don't > really need to change existing code since TPlotScreenBaseLarge will be > compatible with TPlotScreenBase (because of inheritance). You > can get as > many design versions as you need. > > Cons: You get lots of pairs pas+dfm. Ading something to the > base class can > sometimes have funny effects. Deleting something from a > "child" form is kind > of tricky, if at all possible. Some overhead to the final > code (also the > overhead would actually be smaller opesd to your option) > > Hope I didn't jump in long after this thread has been closed... > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > > Behalf Of John Dammeyer > > Sent: Thursday, February 23, 2006 7:20 PM > > To: 'Borland's Delphi Discussion List' > > Subject: RE: Using alternate forms with units. > > > > That appears to be the only way to do this since Delphi > doesn't let me > > link > > a form with a different name to a .pas file in the project. Too bad > > really. > > > > Thanks. > > > > John > > > > > > Wireless CAN with the CANRF module now available. > > http://www.autoartisans.com/products > > Automation Artisans Inc. > > Ph. 1 250 544 4950 > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Marcin Bury > > > Sent: Wednesday, February 22, 2006 11:28 PM > > > To: Borland's Delphi Discussion List > > > Subject: Re: Using alternate forms with units. > > > > > > > > > John > > > > > > if only screen resolution matters I would think about > > > additional procedure that > > > will check the screen resolution on form creation as set all > > > neccessary object > > > properties. On resize event is very helpfull as well - I use > > > it almost on every > > > form positioning and resizing some form objects. > > > > > > HTH > > > Marcin > > > > > > ----- Original Message ----- > > > From: "John Dammeyer" <[EMAIL PROTECTED]> > > > To: "'Borland's Delphi Discussion List'" <[email protected]> > > > Sent: Thursday, February 23, 2006 4:00 AM > > > Subject: Using alternate forms with units. > > > > > > > > > > (Changed text to .dfm from .frm. What was I thinking.) > > > > > > > > Hi guys, > > > > > > > > I have an application that is targeted at two different > > > embedded systems > > > > using two different size LCD displays. When the > initial project was > > > > expanded to the second larger display 1024x768 from 640x480 > > > the client also > > > > wanted a number of additions. > > > > > > > > Now I'm faced with the chore of taking what has become a > > > twin development > > > > stream and bringing it back into 1 since all the neat > > > features of the larger > > > > system are also wanted on the smaller. > > > > > > > > About 90% of the changes are object.width, .height, .left > > > and .top and also > > > > some font sizes. > > > > > > > > There are a few that are WIN98 specific verses WINXP or > > > WINNT but they are > > > > less of a problem with flags kept in the registry to > > > determine personality. > > > > > > > > To determine what the new positions and sizes should be the > > > easiest way was > > > > to copy the .frm file and just re-arrange until I liked > > > what I saw. Any of > > > > the graphical code that depends on the width or height of > > > the graphic can be > > > > dealt with using {$IFDEF} etc. > > > > > > > > What I'd like to be able to do is have PlotScreen.frm become > > > > PlotScreenBIG.dfm and PlotScreenSMALL.dfm but keep the > > > PlotScreen.pas file > > > > name. Is there a way to convince Delpi 5 to use a .dfm > > > file different from > > > > the name of the unit during compilation. Then I could just... > > > > > > > > {$IFDEF LARGE_SCREEN} > > > > ... Somehow use PlotScreenBIG.dfm > > > > {$ELSE} > > > > ... Somehow use PlotScreenSMALL.dfm > > > > {$ENDIF} > > > > > > > > Thanks, > > > > > > > > John Dammeyer > > > > > > > > > > > > > > > > Wireless CAN with the CANRF module now available. > > > > http://www.autoartisans.com/products > > > > Automation Artisans Inc. > > > > Ph. 1 250 544 4950 > > > > > > > > _______________________________________________ > > > > Delphi mailing list -> [email protected] > > > > http://www.elists.org/mailman/listinfo/delphi > > > > > > > > > > _______________________________________________ > > > Delphi mailing list -> [email protected] > > > http://www.elists.org/mailman/listinfo/delphi > > > > > > > > > > _______________________________________________ > > Delphi mailing list -> [email protected] > > http://www.elists.org/mailman/listinfo/delphi > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
