Nieuw Project

[VideoRipper]

Je kunt ook nooit van jezelf eisen dat je eerste experimenten op het gebied van programmeren
in Delphi (of welke taal ook) meteen uitblinken in flitsende, goed doordachte en foutvrije code

Zoals met alles in het leven leer je ook dit met vallen, uitproberen en opstaan.
Gewoon lekker doorgaan zo, dan komt het vanzelf goed.

Greetz,

Peter.

[Slauerhoff]

Dank je Peter. Ik ga zeker door

[Marcel]

• Overbodige quotes verwijderd, zie Quoten

[marcov]

Origineel gepost door Slauerhoff

.. ja, ik was destijds ook erg enthousiast over pascal. Ik hoop niet dat ik domme dingen zeg want ik ben niet echt ingevoerd in de informatica maar ik heb gehoord dat delphi achterhaald is omdat je er geen webapplicaties mee kunt ontwikkelen (?) en dat daarom java en/of visual basic veel worden gebruikt?

De simpelere webapplicaties worden met het goedkoopste (en dus jong) personeel gemaakt.

Embarcadero/Delphi heeft al jaren niks aan evangelisatie naar nieuwe gebruikers gedaan, of het is mislukt (de ene na de andere school is naar Java overgestapt), en dus zijjn de gemiddelde developers wat ouder en duurder.

Dat is de reden waarom de bulk van de goedkope webapps niet in Delphi gemaakt worden.

Ik zit echter in mijn 3/4e (afhankelijk van hoe je het ziet) Delphi gerelateerde baan, en dit is de eerste waar ik NIET een webapp in Delphi heb gemaakt.

[NGLN]

Origineel gepost door Slauerhoff

... ik heb je code goed bekeken ... Maar begrijpen doe ik het niet wezenlijk.

Hmm, als je verder wilt met Delphi, dan ontkom je er niet aan om met objecten te leren werken en dus ook zelf objectgeörienteerd te leren denken. Maar dat moet natuurlijk helemaal in je eigen tempo. Lees for starters eens Createn van Objecten. Bekijk daarna de bijlage waarin ik de Graph-unit van wat commentaar heb voorzien, en waaruit ik de thread en de Bitmaps geheel verwijderd heb. De snelheid zit 'm overigens dus niet in het gebruik van een Bitmap, maar toch echt in MoveTo-LineTo i.p.v. Pixels[x, y] en wellicht in ietwat loop-optimalisatie.

Ik kwam eerst in de verleiding om jouw unit Graph te gaan gebruiken maar dan had ik alles om moeten bouwen en had ik net zo goed opnieuw kunnen beginnen. Ik ben maar op mijn eigen manier doorgegaan...

Wees gerust, het was niet mijn bedoeling om iets kant-en-klaars te leveren, maar om jou een idee te geven hoe het ook en anders zou kunnen. Het is helemaal aan jou of OOP je bevalt, want je kunt in Delphi ook prima procedureel programeren.

[Slauerhoff]

Nou, je bericht sluit heel mooi aan bij mijn probleem! Ik ben er na veel ploeteren idd achter gekomen dat de snelheid inderdaad zit in de move en line properties ten opzichte van de pixels property. Ik heb het hele bitmap gebeuren gelaten voor wat het was en de snelheidswinst is verbazingwekkend. Maar ... de raaklijnen worden niet goed getekend, ze lijken te worden afgebroken en gaan verder waar ze niet verder moeten gaan. Net alsof er ergens een rare discontinuiteit optreedt. Dit is de code:

procedure TForm1.RaaklijnenPlotten;
const dxx=0.1;
var   xx: real;
begin
  xx:=dmin;
   while ((xx<=dmax) and (not stoppen)) do
   begin
    aa:=g(xx); bb:=f(xx)-(xx*g(xx));
    Canvas.MoveTo(conversiex(dmin),conversiey(r(dmin)));
    Canvas.LineTo(conversiex(dmax),conversiey(r(dmax)));
    sleep(5);
    xx:=xx+dxx;
    application.processmessages;
   end;
end;

Ik heb de hele loop gevolgd met Showmessage. Geen rare dingen. Toen heb ik doodgewoon zelf punten als begin en eindpunt opgegeven. Van -5,-9 tot 5,9 > recht. Van -5,10 tot 5,10> rare sprong. Ik kom er niet achter hoe dat kan. Ik voeg voor de zekerheid het hele programma maar weer bij, mocht je dat misschien nodig hebben.

Ik heb je code uitgeprint en goed bekeken. Ik heb er heel veel vragen over, maar dan zit ik hier de hele nacht nog te schrijven

Nee ik vind OOP zeer interessant. Ik kan er niet tegen als ik iets niet begrijp. Je bent goed in je opzet geslagd om te laten zien hoe het anders kan. Zeer bedankt voor je bijlage en de link.

Hoe is zoiets ontstaan? Die omslag van procedureel naar OOP? Slimme denkers en/of de toegenomen snelheid van processoren? Anyway.. die lijn is andere koek; basaler kun je het bijna niet maken. Ik ben daar uren mee bezig geweest en heb telkens de fout in mijn eigen code gezocht, maar volgens mij is het dat toch niet. Ik ben heel benieuwd.

[VideoRipper]

Origineel gepost door Slauerhoff

Nee ik vind OOP zeer interessant.
[...]
Hoe is zoiets ontstaan? Die omslag van procedureel naar OOP? Slimme denkers en/of de toegenomen snelheid van processoren?

Nee hoor, niets van dat alles.

Het is alleen op een andere manier aankijken tegen een probleem: het opdelen
van één groot probleem in kleine sub-probleempjes, waarbij ieder sub-probleem
z'n eigen "Object" is.

Je moet het ook niet te ingewikkeld zien: toen ik de overstap maakte van procedureel
naar object geörienteerd (met Turbo Vision onder DOS), begreep ik er eerste instantie
ook de ballen van

Onder "Ouderwets" Pascal schreef je iets als:

Pascal Code:

1. Program Iets;
2.  
3. Uses
4.   Crt;
5.  
6. Var
7.   Waarde  : String;
8.  
9. Begin
10.   ClrScr;
11.   Repeat
12.     WriteLn('Voer een tekst in...');
13.     ReadLn(Waarde);
14.     ClrScr;
15.     WriteLn('Je tikte de tekst "' + Waarde + '" in!');
16.   Until (Waarde = 'stop');
17. End.

Je begon bij het begin, liep de code door van boven naar beneden, totdat er aan een
bepaalde voorwaarde was voldaan en je stopte weer.

Onder een grafische omgeving, zoals bij Windows, is het eigenlijk heel onhandig
om te werken met een enkel scherm waar tekst van boven naar beneden geprint
wordt en waar je in datzelfde scherm ook in een bepaalde volgorde input van jou
verwacht wordt.

Het mooiste zou dus zijn wanneer je, afgaande op bovenstaande Pascal-code, de
beschikking zou hebben tot "Iets" wat een tekst kan weergeven en een ander "Iets"
waar een gebruiker weer tekst in kwijt kan.
Een derde "Iets" geeft de code de opdracht om dan iets te doen wanneer de gebruiker
dat pas wilt (de klant is tenslotte koning, niet de software).

Deze "Ietsen" noemen we dan "Objecten" en deze objecten zijn zelf verantwoordelijk
voor hetgeen ze geschreven zijn.
Het zouden dan bijvoorbeeld in dit geval een TLabel, TEdit en een TButton kunnen
zijn.
Een TLabel zorgt ervoor dat tekst weergegeven kan worden in een apart venstertje,
een TEdit geeft de gebruiker de mogelijkheid om tekst in te voeren en op een TButton
kan de gebruiker drukken wanneer hij dit wilt.

Je kunt dit dan vergelijken met een team: je hebt een manager ("De baas" - jij dus) die
alle zaken overziet en die tegen Pietje (TLabel) zegt: "Ga daar in het kantoor staan en
hou dit A4'tje vast met deze tekst".
Klaas (TEdit) moet als luisterend oor dienen voor inkomende teksten en Jan (TButton)
moet de manager een gil geven wanneer er iemand bij hem aanbelt.

Als manager hoef je je dus helemaal geen zorgen meer te maken over de werking
van deze "Werknemers": zolang je ze goed aanstuurt (positie op een formulier, de kleur,
afmetingen, ...), kun je ze gewoon aansturen door eerst hun naam te roepen, daar een
punt achter te zetten, gevolgd door hetgeen je wilt instellen of uitlezen.

Delphi Code:

1. Procedure TTestForm.FormCreate(Sender: TObject);
2. Begin
3.   Label1.Caption := 'Voer een tekst in...';
4.   Edit1.Text := '';
5. End;
6.  
7. Procedure TTestForm.Button1Click(Sender: TObject);
8. Begin
9.   If (Edit1.Text = 'stop') Then
10.     Close
11.   Else
12.     Label1.Caption := Edit1.Text;
13. End;

Eigenlijk verschilt object geörienteerd niet zo heel veel van procedureel programmeren;
code wordt nog steeds van "Begin" tot "End." uitgevoerd, alleen het verloop van de code
is van te voren niet voorspelbaar en is geheel afhankelijk van de input van de gebruiker
(alles is "Event-driven").

Het grote voordeel van OOP is dat jij, als programmeur (of manager), niet alles zelf
hoeft bij te houden, maar dat alle objecten dit voor je doen.
Slechts (of pas) als jij dat wilt, kun je dingen instellen, opvragen en uit laten voeren
zonder dat je je er zorgen over hoeft te maken of het wel goed gebeurt.

Greetz,

Peter.

[NGLN]

Origineel gepost door Slauerhoff

Toen heb ik doodgewoon zelf punten als begin en eindpunt opgegeven. Van -5,-9 tot 5,9 > recht. Van -5,-10 tot 5,10> rare sprongen. Ik kom er niet achter hoe dat kan.

Dit is very weird! 'k Snap het ook niet, ben echt verbaasd. Het enige wat ik kan bedenken is dat het met het tekenen op het Canvas van het Form zelf te maken heeft. Als je tekent op een TPaintBox of TImage, dan gaat het wel goed.

[Slauerhoff]

Peter: Bedankt voor je uiteenzetting. Dat wat jij beschrijft had ik zelf ook al een beetje bedacht Ik heb het ook zo wel eens gezien; als je nu een opdracht geeft en na de punt een subopdracht dan roep je een procedure aan die op zijn beurt weer een subprocedure aanroept. Dit alles staat dan ergen in een unit. Maar dat zal te simpel zijn. Als ik de code van Bart lees dan gaat het toch dieper. Pointers en Dynamische Arrays schijnen erg belangrijk te zijn. Dat is van voor de tijd van TP. Het is begrip class is voor mij ook vaag. Maar ik kom er wel achter. De boeken voor beginners die ik heb gaan daar niet diep op in.

Albert: Dus voor jou is het ook een raadsel. Dat had ik niet gedacht Maar inderdaad, het heeft iets te maken met het alleen op het form zelf te tekenen. Ik heb het ook met een TImage geprobeerd maar dan krijg ik heel gekke verschijnselen. Het scherm gaar flikkeren en alles wordt zeer langzaam getekend. Maar ik zal die kant toch weer op moeten. Wat is het verschil tussen Image en Paintbox?

.. ik meld me later wel weer

[Slauerhoff]

.. ik ben benieuwd wat jullie er van vinden!

[Bart B]

Origineel gepost door Slauerhoff

Wat is het verschil tussen Image en Paintbox?

Het verschil in gebruik (om het heel simpel te houden) is dat alles wat je op een image tekent er ook blijft staan (of liever gezegd weer opnieuw getekend wordt) als de image tijdelijk geheel of gedeeltelijk onzichtbaar was op het scherm (verborgen achter een ander venster bijv.), terwijl de paintbox dat niet doet.

E.e.a kost overhead en is daardoor (als je daar niets aan doet) trager dan een paintbox.
Dat geflikker kun je waarschijnlijk reduceren door de property DoubleBuffered van de TImage op True te zetten.

Een gebruikelijke manier om snelheid te winnen en gelikker te voorkomen is om het hele (of deel van het) plaatje eerst in een bitmap in het geheugen te tekenen (een soort scratch-pad a.h.w.), en deze dan in zijn geheel te kopieren naar je image op het scherm.

Bart

[NGLN]

TImage is een component waarmee je heel gemakkelijk afbeeldingen van diverse formaten (jpg, bmp, ico, wmf, etc...) kunt weergeven. Een TImage heeft tevens een eigen Canvas, maar wat je daar op tekent blijft niet zondermeer automatisch staan.

TPaintBox is een component waarop je kunt tekenen. Dit component is een stuk "lichter" dan een TImage. Ook hierop blijft de tekening niet vanzelf staan, teken daarom in de OnPaint eventhandler.

Bart_B: DoubleBuffered is een property van TWinControl, dus die zou je van de Parent van de Image (of PaintBox) kunnen instellen om flikkering te voorkomen.

Slauerhoff: Leuk, ziet er goed uit!

[Slauerhoff]

ok. Bedankt voor jullie reacties. Ik weet dat ik vervelend ben maar ik voeg nogmaals het programma toe vanwege uitbreidingen/verbeteringen. Maar er is nog iets wat ik nbiet voor elkaar krijg; dat de schuifjes van de scrollbars op de goede posities worden gezet. Als ik fixed op true zet in de controls groupbox kan ik door een schuifje te verplaatsen de functie meteen laten tekenen zodat het effect van d, a, b, en c duidelijk wordt. Eerder met de zetpixel methode was dat uberhaupt niet mogelijk. Nu met de moveto/lineto wel, maar het gaat nog steeds traag. Wat ik ook niet begrijp is het snelheidsverschil. Een lijn moet zo ie zo getekend worden en ook die lijn is opgebouwd uit pixels. Maar ik vermoed dat het iets te maken heeft met jullie opmerkingen betreffende eerst een afbeelding naar het (video?) geheugen schrijven en pas dan op het scherm zetten. Die pixels worden denk ik rechtstreeks naar het scherm gestuurd. Enfin .. zonder jullie en deze site was dit me nooit gelukt. Of ik had er in ieder geval veel langer over gedaan. Trouwens .. waar vind ik door jullie geschreven programmatuur?

[Slauerhoff]

.. hiermee vervalt de vorige ZIP. 't Is nu wel klaar denk ik. Probeer dit eens: laat functies genereren en stel het domein dan in op 2 of 3. Zelf vind ik dit erg mooi.

[Slauerhoff]

.. ik meende dat ik klaar was maar het blijft me bezig houden. Met checkboxes en scrollbars kan ik het plotten van de raaklijnen als het ware finetunen. Het enige probleem dat overblijft is dat als ik hem instel op het plotten van enkele lijnen dan wissen (overschrijven) de lijnen de functies (pixels). Ik heb dat proberen te ondervangen door wat gewist wordt weer opnieuw te plotten. Maar dat werkt niet goed en bovendien wordt het programma er duidelijk trager door. De informatie in TEdit moet dus opgeslagen worden en later tijdens het plotten van de raaklijnen vanuit het videogeheugen op het canvas worden geprojecteerd. Althans, als dit kan. En zo ja, hoe. Dank alvast