19. juni 2000 - 12:08Der er
51 kommentarer og 5 løsninger
Formindske programstørrelse(Undgå forms)
Hello, hvordan laver man sit program uden brug af forms? Indtil videre har jeg har jeg fjernet Unit1 og unitten forms og vil så skrive programmer inde i Project source det ser sådan ud:
program Project1;
uses ;
{$R *.RES}
begin Application.Initialize; Application.Run; end.
Problemet er blot det at det ikke bliver "kørende" det afslutter når koden er blevet ekserveret. Mit spørgsmål er så hvordan holder man det kørende?
Hvis du skal holde programmet kørende, når det er uden forms, må du selv udføre et uendeligt loop. Dog skal det lige siges at du ikke bare helt bilndt skal laven en
While true do begin bla. bla. bla. bla. bla. end;
Du skal implementere det i en tråe således du ikke gør krav på unødige resourser ....
Der er også varmt her oppe i dag. Vejr guderene har lagt hårt ud her fra morgen stunden og bragt tempraturen over 3 graders varme ! Tempraturen her været over fryse punktet i snart 14 dage nu ... Det er næsten ulideligt .... :o)
Jeg vil anbefale at du laver det som en service (vælg File, New, New, Service) og lav dit program deri. Efter at programmer er færdigt skal det installeres som en service og kan så strates/stoppes via "Service Manager".
Så ser du det ingen steder undtagen i service oversigten / joblisten-processer, og det kan endda køre uden at der er logget en bruger på.
Så selvom det måske ikke helt er det du leder efter, så hvorfor ikke... ?
>Borrisholt Jeg er bange for at: "de ikke vil betale prisen" (eller så er det mig der ikke vil <G>)
>frifoed Joh services er kun for NT (herunder også W2K). En tråd er såmænd bare det "danske udtryk" for "Threads" (se evt. Delphi's hjælp vedr. TThread)
Ikke korrekt (heller ikke hvad Linux angår). Det du slår ned i Linux (med kommandoen "Kill 312") er ikke en tråd, men derimod en Process (nummeret 312 som du brugte er således et PID - Process ID). En process består altid af MINDST "en tråd", men kan godt bestå af flere.
Når/hvis du splitter dit Delphi program op i tråde så kan du styre prioriteringen af dine tråde og derved bruger du ikke så meget CPU power. Programmering med tråde er ikke så svært som man måske kunne tro ved første øjekast, men de fleste træder 2 skridt tilbage første gang de ser det.
Du kunne også vælge at bruge en TTimer. Den er ikke så "effektiv" som en tråd, men det er en nem måde hvorpå du kan begrænse "CPU-forbruget".
Helt konkret hvad er dit problem? Hvorfor "går du op i" hvad din application fylder. Hvis du har lavet den rigtig så indeholder den kun det den skal indeholde og så fylder den det den skal (Jo os der startede på en VIC20 - med 3.5 Kb og en clockfrekvens der kunne måles med et timeglas - ved godt hvordan man skriver effektive kode <G>).
Er dit primære mål, at nedsætte programstørrelsen, eller er det bare at gemme formen for brugeren? For hvis det er det sidste du vil, er der en langt nemmere løsning.
Ret i din project-unit og indsæt én linie:
program Project1;
uses Forms, Unit1 in 'Unit1.pas' {Form1};
{$R *.RES}
begin Application.Initialize; Application.ShowMainForm := False; //Dette er linien du skal indsætte. Application.CreateForm(TForm1, Form1); Application.Run; end.
retep> Det er egentlig begge dele :-) I mit nuværende program har jeg formen skjult men da den ikke skal bruges til noget hvorfor så have den? Og grunden til at jeg ønsker en mindre programstørrelse er blot at jeg kunne tænke mig at vide hvordan det gøres.
Jeg skrev en "større afhandling" i går, men den blev åbentbart ikke "fanget" af eksperten's-system, så vi prøver igen. Ovenstående dækker meget godt hvordan du undgår din form, men med hensyn til størrelsen så vil jeg stadig mene at den "bedste mulihed" er at lave din application som en Console Application (File->New->Console Application) - i det omfang hvor du alligevel ikke har bruge for VCL componenterne (evt hvis du vil lave en "CGI Application"
Der udover har du flg. muligheder: 1) Undlad at "Use" units som du alligevel ikke bruger. 2) Undlad at compile dit program med diverse debug-informationer: Project->Options->Compiler (fjern samtlige "checkmarks" under "Debuggeing) 3) Denne sidste mulighed vil nedbring størrelsen af din EXE-fil (meget), men vil ikke nedbringe hele størrelse. Et VB (VisualBasic) program behøver ikke af fylde ret meget det er fordi at et VB program kræver at der foruden programmet installeres et runtime library. Dette giver den fordel at EXE filen nedbringes (flere VB programmer bruger samme runtime-library, som således kun skal installeres en gang), men det giver samtidig den ulempe at programmet ikke kan køre med mindre runtime libralry'et er installeret. På samme måde kan du hved hjælp af packages oversætte dit Delphi program således at disse packages ikke linkes direkte ind i EXE filen, men i stedet ligger separat. Mange forsk. Delphi programmer kan således anvende samme packages (se evt. Project->Options->Packages), men på den anden side så skal du sørge for at disse installeres (programmet vil ellers ikke virker). Selvfølgelig skal du kun "medsende" de Packages som dit program gør brug af. Hvis du selv udvikler "biblioteker" og/eller komponenter skan du med fordel (størrelses mæssigt) pladcere disse i packages sålede at flere af dine programmer anvender samme packages.
Personligt har jeg ikke gjort brug af Packages da det kan give nogle problemer. Har brugeren disse packages i forvejen? Hvis ikks så skal de installeres? Hvad nu hvis en bestemt package er blevet kaldt det samme i evt. Delphi 4 og 5 (jeg mener at Borland's egner packages IKKE har dette problem, men "forkert producerede" 3rd party kunne være ramt af dette problem).
Nej een EXE-fil der indeholder det hele vil jeg foretrække, hvad enten den fylder 53 Kb eller 17.8 MB :-)
I forlængelse af pellelil vil jeg da godt nævne at hvis størelsen på exe filen er et kardinalpunkt, så bør du nok skifte sprog. Det er ikke i væsenlig grad muligt i DELPHI at skabe små programmer, målt i størelsen på exefilen. Til det formål vil jeg anbefale Microsoft Visual C++ og der i gøre brug af MFC klasserene, så kan du skabe reletiv små programmer. Tilgængæld ved dem af os der har prøver VC++ at der også er en pris der skal betales.
Du kan sagtens I Delphi lave lige så små programmer, men så skal du holde dig fra VCL'erne og selv lave "det hele" (binde en event-handler til dit vindue og alt sker vedhjælp af diverse WIN32 API kald).
Ideen med dynaminsk linkning af Packages er vel også at nedbringe størelsen af store applikationer. Jeg mener at man i stører systemer med fordel kan bruge dynaminsk linkning af Packages, fordi du ikke compiler det samme kode med flere gange. Det kræver naturligvis at man distribuere sine Packages sammen med sit program, men det er vel heller ikke et problem hvis man i forvejen skal medgive 200 DLL filer ?
Borrisholt> Enig. Jeg har over flere år udviklet et "bibliotek" (grund ideen stammer for nogle af tingene "helt tilbage" til TurboVision 7.0). Jeg har aldrig tage min r.. sammen til at putte dette hverken i en DLL eller en package, men jeg kunne med stor fordel gøre det (hvad angår størrelse), da denne "samling" linkes ind i samtlige programmer jeg laver.
Jeg har tit undret mig over at ikke flere Delphi programmøre (jeg selv medregnet) ikke blot distribuere deres produkter med "eksterne packages". Men når det ha aldrigt rigtigt slået an, så er det nok fordi: "if it aint broken don't fix it".
Det er nogle interresante bud, jeg har imidlertid også fundet et freeware-program der har formindsket mine programmers størrelse 50-70% (her er der ikke tale om pakke-programmer) Har sådanne programmer ulemper? Det med at lave hele skidtet i Win32 Api lyder meget interessant og udfordringsrigt hvordan gøres dette? Hvor får man fat i api-calls til alt?
frifoed > Jeg er glad for at dy syned det er interresante bud du har fået, forid du har i hvertfald fået mange :o)
Det der med API kald til det hele ... Tjo ... Start med den alm. Delphi funktion og så kig i sourcen hvordan Borland har implemteret det ... Så kommer du langt .... Ellers kig i diverse C++ bøger, der står tit mange gode ting at hente. Det kræver dog at du er familiær med C++ syntaxen ....
Charles Petzold (undskyld hvis jeg ikke har stavet det korrekt, bogen står "der hjemme") har lavet nogle gode Windows bøger (C++) netop om emnet (de er fra Microsoft Press)
frifoed> Delphi egner sig som ganske fint - men det er ikke C++ som windows er skrevet i. Derfor "problemerne"..
Jeg kan anbefale bogen "The Tomes of Delphi 3: Win32 Core API" - ISBN: 1-55622-556-3 - og selvom der står delphi 3 i titlen, så er API'en jo altså stadig den samme, da det er selve windows... Den har alt med hvordan du får komplet kontrol over dine programmer og windows - incl. hvordan du kan definere dine egne window-classes, registrere dem med windows, og skabe instanser af dem. Det er lidt langhåret (eller rettere, det fylder en del), men lade-sig-gøreligt..
Selvfølgelig er det muligt at lave ALT med API efter som delphi principielt bare er "Pascal wrappers" til diverse API kald. Det store spørgsmål er bare hvor meget du "gider" at lave selv
pellelil> well jeg har ICS komponenterne men disse er jo VCL så dem kan jeg ikke bruge. Hvordan laver man FTP-server, telnetserver og socketforbindelser med Api? Er der en oversigt over kommandoer et eller andet sted?
Ja, i hjælpen og i sourcen. Hvis du kigger på Borlands source så er de jo netop "nødt til" at bruge diverse API kald for det er "det eneste du har at arbejde ud fra". Ligeledes hvis du kigger i ICS sourcen kan du se hvordan disse er programmeret. Du finder ikke et enkelt API kald der overføre en fil fra en FTP-Server til en FTP-Client.
I dit sted ville jeg personlig "finde mig i" at programmerne fylder det de gør. Hvis du selv vil til at skrive "det hele" fra bunden kan jeg kun ønske dig held og lykke. Det er en MEGET stor mundfuld og chancerne for at du introducere en række fejl (der ikke ville være fremkommet hvis du "bare" brugte de værktøjer du har er rundt regnet lig 125%. Ligeledes er du nødt til (på bit niveau) af vide hvad det er de enkelte API gør hvorfor du netop skal sætte parametrene som du gør osv.
Skal det være nemt, hurtigt og pålideligt (sidst nævnte afhænger af "hvem" der har skevet komponenterne), så brug Delphi som det er. Hvis du selv vil ha' 100% kontrol, sørge for at programmet ikke fylder mere end nødvendigt så skal du smøge ærmerne op og "get you hands dirty".
Jeg tror at jeg vil kaste mig ud i det! Som du siger er det noget avanceret skidt men det er vel den eneste måde man kan lære det på. Og siden at jeg kun er hobbyprogrammør der ikke har nogle deadlines så hvorfor ikke udnytte min gymnasie tid og lære noget hardcore programmering.
Hvis du vil lære "hardcode" så glem Delphi og lær i stedet C++. Ikke fordi Delphi ikke kan gøre det "lige så godt" men fordi du stort set ikke finder noget "hardcore information" der ikke er skrevet af-og-til C++ programmøre. Alle MS's Recerence Libraries er C++ orienterede. Jeg har netop fået min "Active Directory Developers Reference Library" (W2K), og jeg skal til at "stave mig gennen disse C++ eksempler" hvis jeg vil gøre mig håb om at lave en "Delphi udgave" (håber at en "venlig sjæl" kommer mig i forkøbet og lægger noget ud i Delphi-Jedi).
Jeg "tager hatten af" for din holdning (hvis du VED hvad det er du går ind til). Jeg har kigget lidt i ICS koden og det første sted du skal starte er selve SOCKET'en. Denne finder du eksempelvis i WSocket.pas (189 KB Pascal kode). Du skal bare dykke ned og kigge på de API kald François PIETTE benytter. Jeg kender ikke hans "baggrund", men med det ringe kendskab jeg har til dine evner så tror jeg ikke at du skal ikke regne med at du har noget der VIRKER de første 3-8 mdr (ikke pga. dig - som jeg ikke kender - men på grund at "emnet).
Jeg foretrækker stadig "bare" at bruge det frem for at vide hvad f..... da sker i baggrunden (if it iant broken don't fix it)
humm hvis du vil vide hvad jeg kan/ikke kan så er det meget simpelt. Jeg er 16 år har selv lært Pascal(Delphi) kan alt vad der har med syntaxen at gøre og alt hvad jeg har kunnet læse mig frem til. Så vidt jeg forstår er Api(application programming Interface) selve kernen i windows-programmering og det er denne jeg kunne tænke mig at beherske. Det må jo være det ultamative indefor Windowsprogrammering! Det må være ligesom at have skipperskræks spinat eller Merlins tryllestav. Dog er jeg stadig kun en "grøn" programmør med kun en lille erfaring (har haft et betalt freelance job). Men hvorfor hvile på laugerbærene? Verden er ung og jeg har sommerferie!
Du har så evigt ret: Standard Delplhi (VCL-baserede) componenter kan løse 90% af din programmering, men til resten er du nødt til at smøge ærmerne op og her kommer Windows API til sin ret.
API betyder ganske rigtigt Application Programming Interface, men det er ikke ubetinget en hverken Microsoft eller Windows ting. Det er såmænd bare "et udtryk" der dækker at der er et "interface til et eller andet". Jeg kunne eksempelvis lave et API der åbner op for 3. parts programmøre at "stikke snablen" ind i mine egne programmer. På samme måde har MS dette interface for at vi kan stikke snablen ind i "maven af Windows".
Alt officielt MS documentation vedr. diverese APIer vil altid være C++ orienterede, men netop fordi VB er deres eget produkt vil der nok komme mere på denne front også. Vedr. Delphi så kan du rundt omkring finde lidt, men det er de færreste der har skrevet de "helt store afhandlinger".
Men at du vil skrive det hele selv er (i min bog) at gå "for langt". Med changen for at lyde som en "blærerøv" vil jeg alligevel sige at jeg ligger i den gode ende af den bedre halvdel, men alligevel kunne JEG ikke finde på at sætte mig ind i alle APIer da dette er formålsløst (og endnu har vi kun 24 timer i døgnet).
En ting er API en anden er "generel viden". Hvad ved du f.eks. om OSI's 7 lags model, protokoller i TCP/IP suiten og når jeg siger protokoller så mener jeg ikke deres navn eller deres funktion, men NØJATIGT hvordan de ser ud (hvilket bit er sat HVOR og navnlig HVORFOR). Dette er en videnskab i sig selv der tager lang tid at beherske og først når du ved hvordan det skal være kan du begynde at programmere det (via API kald). Hvis du alligevel vil læse mere om "dette emne" så kig efter diverse RTF'er som omhandler de områder der fanger din interesse).
Jeg ville alligevel (selv om man har en lang sommerferie - dit heldige asen) nøjes med at sætte mig ind i de API kald som du har "brug for", og lad resten være oå til dem der "har fået en bog i hovedet" (Hr. PETTE ved sku' nok hvad han har med at gøre !!!). Du kunne med fordel bruge sommerferien på i stedet at lære alt det du kan bruge disse componenter til.
tjaa pellelil, det er måske at satse stort men hvor er man hvis man ingen mål har? Så ligger man sammen med alle pessimisterne og jantelovshåndhængerne hvilket jeg ser som en sørgelig ende på vejen. Men jeg er helt enig med dig i at man skal have sin baggrundsviden iorden, og hvor stor forskel gør det egentlig om ens program fylder 80Kb eller 265 når det store har taget en måned og det lille et år? Men jeg tror sgu jeg følger dit råd og sætter mig ind i ICS istedet for at kaste mig ud i Api lige med det samme (det kan vente til jeg kommer på Uni) for der er vel ingen grund til at opfinde den dybe tallerken to gange?
Jeg vil så fuld og helt tilslutte mig pellelil svar. dog vil jeg gerne forlænge det lidt. Hvis du ønsker et dybere indblik i fx. win32 API'en skulle du tage en eller to funktioner af gangen og kode en eller anden lige gyldig application ovenpå den. Vigtigst af alt skal du GEMME din kode, fordi, en anden gang sidder du pg laver noget brugbart, hvor så du får brug for NETOP denne funktion.
Hvis du kigger på min hjemme side http://borrisholt.com finder du en masse eksempler på små, isoleret set, ubruglige applicationner, men som alligever kan bruges i en stører sammenhæng.
Jeg mener det er en ogd måde at starte på Windows API'en, ller en anden APi på, for så på den måde at få opbygget et kode bibliotek, som du senere kan drage nytte af ....
>Frifoed "du har tiden" så borrisholt's ide er ikke dum, og du kan den vej igennem lære mange ting som du senere kan bruge (hvis du eller kan huske hvor du har gemt koden <G>). Vi andre må nøjes med at "lege" når vi sidder med et konkret problem der skal løses igår (vi er nødt til at ha' ondt af os selv, der er ikke andre der vil <G>). Med de evner du har som 16 årig kan du nå langt hvis bare du har lysten jeg started selv med en VIC20 i konfirmations-gave.
Jeg sidder i dag i en intern IT afdeling (i en virksomhed er ikke ellers har noget med IT at gøre) men har tidligere i flere år være ansat som udvikler ( siden dengang det hed PolyPascal/TurboPascal 3.0). Du kan være sikker på een ting, dine kunder er FULDSTÆNDIG LIGEGLAD om koden fylder 80 kb eller 3 MB. Du er bestilt til at løse en opgave, og enten virker applicationen som den skal ellers gør den ikke. Kunderne er er også Græsk/Katolske om du har "kodet API'erne selv eller ej".
begin WindowClass.hInstance := HInstance; If Windows.RegisterClass(WindowClass) = 0 Then Begin MessageBox(0, \'Not enough ressources for initialization\', \'Error\', IDOK); Exit; End;
FHandle := CreateWindow(WindowClass.lpszClassName, MainCaption, WS_POPUP or WS_CAPTION or WS_CLIPSIBLINGS or WS_SYSMENU or WS_MINIMIZEBOX, 200, 400, 0, 0, 0, 0, HInstance, nil); If FHandle = 0 Then Begin MessageBox(0, \'Not enough ressources for initialization\', \'Error\', IDOK); Exit; End;
Terminated := False;
Repeat If PeekMessage(Msg, 0, 0, 0, PM_REMOVE) Then Begin If (Msg.Message = WM_QUIT) Or (Msg.Message = WM_CLOSE) Then Terminated := True;
TranslateMessage(Msg); DispatchMessage(Msg); end; Until Terminated;
If FHandle <> 0 Then Begin DestroyWindow(fHandle); Windows.UnregisterClass(WindowClass.lpszClassName, FHandle); End; end.
borrisholt > jeg er også begyndt at lege med PHP+MySQL :-) Det er fandme fedt! Jeg er igang med et større projekt som jeg lige poster når det er færdigt. C++ syntaxen er egentlig meget nem at have med at gøre i forhold til Pascal. Men jeg er dog stadig TOTALT newbie i c++/php.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
