MT4 DLL-geheugenvervuiling - Page 4
Page 4 of 635 FirstFirst ... 2345 LastLast
Results 31 to 40 of 41

Thread: MT4 DLL-geheugenvervuiling

  1. #31
    1 bijlage (n)
    Quote Originally Posted by ;
    Als u de codeafmeting verder wilt verkleinen, kijkt u naar de projectopties onder Koppelingen, schakelt u alle foutopsporingsinformatie en regelnummers uit en schakelt u strippatronen in voor de definitieve release. Schakel ook altijd smart linking en smart linkable in. Dit zou de grootte van de gegenereerde .exe- en .dll-bestanden verder moeten verkleinen.
    Bedankt voor alles 7bit, je antwoord en bijdrage zijn geweldig !! Mag ik dus een vraag: u zegt:
    Quote Originally Posted by ;
    Als u een nieuw DLL-project wilt maken (als u Lazarus voor de eerste keer hebt gestart), klikt u op Projectprojectbibliotheek projecteren. Geef het een betekenisvolle naam en sla het op in een lege map. Het project bestaat aanvankelijk uit slechts twee bestanden. Een .lpi-bestand met alle compiler-instellingen en en. Lpr-bestand met de broncode; deze twee bestanden zijn alles wat u nodig hebt om een ??????back-up te maken, door te geven aan uw collega's of te beheren in een broncode-repository. Extra eenheden (als u besluit grotere projecten op te splitsen) worden opgeslagen als individuele .pas-bestanden.
    Maar wanneer ik een nieuw project maak als een DLL, produceert Lazarus eigenlijk meer bestanden:
    Wanneer ik vervolgens mijn project probeer te compileren, produceert het geen dll maar een .exe-bestand. Ik bedoel in het geval van een .dll-bestand .exe. Ik heb veel tijd geprobeerd sinds 2 uur, en heb net gekopieerd om je code in een nieuw bibliotheekproject te plakken. Het geeft: Ingevoegd codebibliotheek Project1; {$ mode objfpc} {$ H } gebruikt klassen {u kunt hier eenheden aan toevoegen}; {$ IFDEF WINDOWS} {$ R AHL1.rc} {$ ENDIF} begin met einde. Maar dan, als het gecompileerd wordt, produceer het gewoon een .exe. Ik google om op zoek te gaan naar een antwoord op dit probleem, maar het lijkt erop dat dit gebeurt met andere, maar niemand antwoord: dus mis ik iets in de configuratie misschien?

  2. #32

    Quote Originally Posted by ;
    Maar wanneer ik een nieuw project maak als een DLL, produceert Lazarus eigenlijk meer bestanden:
    De .lpi en de .lpr zijn degenen die alle informatie bevatten, de andere worden gegenereerd. Wat betreft uw screenshot: ik kan daar niets zien. Schakel het verbergen van bestandsnaamextensies in uw Windows Verkenner uit. Hoe kunt u uw computer productief gebruiken als u deze hebt ingesteld om de helft van elke bestandsnaam (de belangrijke helft even) voor u te verbergen (en voor mij als ik naar uw schermafbeelding kijk)?
    Quote Originally Posted by ;
    Wanneer ik vervolgens mijn project probeer te compileren, produceert het geen dll maar een .exe-bestand. Ik bedoel in het geval van een .dll-bestand .exe.

  3. #33
    Ook een paar plaatsen geleden schreef je dat het dll-voorbeeld met Lazarus werkte, dus je moet in de tussentijd iets veranderd hebben. Als je alle instellingen volledig in de war hebt geroepen, probeer ze allemaal terug te zetten naar hun standaardwaarden, misschien zelfs een nieuwe installatie als niets helpt. Wees ook voorzichtig met de optie Comiler-instellingen gebruiken als standaard voor nieuwe projecten, dit kan verwarring veroorzaken als u een nieuw project start en niet alle speciale instellingen onthoudt die u in het laatste project hebt gemaakt (en waarom), vooral als u nog in de experimentfase totdat je bekend bent met alle instellingen. Het kan bijvoorbeeld de naam voor de doelbestandsnaam hebben onthouden en als u eerder enkele experimenten met .exe-bestanden hebt uitgevoerd en een .exe-bestandsnaam hebt opgegeven en hebt aangevinkt als standaard voor nieuwe proecten en dan zullen alle nieuwe projecten deze doelbestandsnaam en zelfs bibliotheken gebruiken zal dan hun uitvoerbestand hernoemen naar deze .exe bestandsnaam omdat het in de projectopties is totdat je het verwijdert en als nieuwe standaardwaarden opslaat.

  4. #34
    Quote Originally Posted by ;
    De .lpi en de .lpr zijn degenen die alle informatie bevatten, de andere worden gegenereerd. .......... .............. Als ik ten onrechteper ongeluk een doelbestandsnaam heb ingesteld die eindigt op .exe, wordt het bestand .EXE natuurlijk genoemd als gevraagd maar het zal geen exe zijn, het zal nog steeds een .dll zijn, alleen met de verkeerde naam.
    Hallo, het werkt nu! Ja, je hebt gelijk, ik moet mijn vensters op een meer technische manier instellen! Dus in alle gevallen, compileer Lazarus nu .dll volgens mijn projecttype keuze. Maar ik moest iets een beetje anders doen: oprecht totdat het systematisch een .exe compileerde. Dus moest ik een nieuw project maken en een compleet ander type kiezen, geen .exe-app of dll, ik koos FPC Unit console ect ... en compileer er een project onder.Ik sluitOpen Lazarus opnieuwen maak een nieuw project als een bibliotheek (dll), dus nu werkt het prima. Misschien kunnen ze cachegeheugen of iets ergens zijn en moet het worden gereset ... of misschien omdat mijn installatie nieuw is. Bedankt voor alles 7bit!

  5. #35
    Vond dit gewoon wat relevant kan zijn voor het probleem met de .dll uitgevoerd als .exe
    http://www.lazarus.freepascal.org/in....msg39170.html

  6. #36

  7. #37

    Quote Originally Posted by ;
    [code] Var s: string; var p: pchar; s: = string (p); setlength (s, strlen (p));
    Is het mogelijk om dit op de een of andere manier te automatiseren? Misschien via compiler-derivaten of wat al niet? Ik heb een algemene vraag over Lazarus. Heb ik gelijk als ik begrijp dat de meeste code Win32-specifieke code die openbaar beschikbaar is voor Delphi niet gemakkelijk bruikbaar is in Lazarus? Zo ja, welk praktisch voordeel heeft Lazarus ten opzichte van Delphi? Ik heb Lazarus de afgelopen week of zo gebruikt en ik vind het echt leuk, maar ik vraag me af of ik in plaats daarvan delphi moet gebruiken. Werkt interactie met MT4 op exact dezelfde manier in Delphi? Is er een verschil in PChar - gt; Ansistring conversie of alles wat ik moet weten voordat ik Delphi probeer?

  8. #38

    Quote Originally Posted by ;
    Je zult veel van de win32-specifieke code direct in Lazarus kunnen gebruiken en compileren voor windows, maar je zult wat herschrijving nodig hebben als je dergelijke code onder Linux of Mac wilt compileren. De aanbeveling om Win32-specifieke API niet te gebruiken, is simpelweg om jezelf niet te beperken tot het Windows-platform. Als u een nieuw project vanuit het niets opstart, zou u alleen de cross-platform API's van RTL, FCL en LCL en aanvullende cross platfom-componenten moeten gebruiken die vrijwel alles vervangen wat u ooit zou kunnen doen met de Windows API. Lazarus heeft het voordeel dat je op een delphi-achtige manier kunt ontwikkelen (en tot op zekere hoogte de bestaande Delphi-code kunt hergebruiken) en dezelfde identieke code kunt compileren op veel verschillende platforms (terwijl Delphi alleen beschikbaar is voor i386windows). Het tweede (en voor sommige mensen het belangrijkste) voordeel is dat Lazarus Open Source is en dus kan geen enkele commerci�le entiteit het ooit meer van de gemeenschap wegnemen (denk aan het Kylix-debacle).
    Quote Originally Posted by ;
    Het zou allemaal min of meer exact hetzelfde moeten zijn. De posting die je citeerde met het casten van de string is een van de weinige uitzonderingen waar sommige kleine details enigszins van elkaar verschillen (en zelfs niet gedocumenteerd lijkt dit een fout in Delphi te zijn). Als u nog geen Delphi bezit, is er geen reden om het te kopen. De algemene trend is dat mensen hun code van Delphi naar Lazarus porteren, en niet andersom. Lazarus is de escape-pod� die nodig is wanneer iemand op de commandobrug van het Delphi-ruimteschip (opnieuw) op de zelfvernietigingsknop drukt. Tussen haakjes: er is een nieuwe versie van Lazarus onderweg, na bijna twee jaar hard werken zal de 0.9.30-versie snel worden uitgebracht. De tagged in SVN al, release-kandidaten zijn al getest, het is maar een kwestie van dagen. _____ �) Het is eigenlijk veel meer dan dat.

  9. #39
    In dat geval blijf ik bij Lazarus
    . Ik stel het erg op prijs dat je DLL's maakt met Lazarus-thread; het heeft de manier waarop ik dit spul programmeer helemaal veranderd. Ik heb een vraag als je een minuut hebt - ik heb een programma gemaakt in Lazarus dat het TSimpleIPC-pakket gebruikt om communiie toe te staan ??????tussen twee afzonderlijke MT4-testers. Ik gebruik TSimpleIPCServer.OnMessage om berichten in het servergedeelte te verwerken. Het probleem is dat de client niet van tevoren weet wanneer de server beschikbaar komt. De manier waarop ik het nu heb gecodeerd, is dat de client blijft controleren of de server beschikbaar is. Als dit niet het geval is, wordt de slaapstand (5) gebruikt en wordt vervolgens opnieuw gecontroleerd. verzonden: = False; herhaal als client1.ServerRunning dan client1.Connect begint; client1.SendStringMessage (outstr); verzonden: = waar; client1.Disconnect; eind anders begin Slaap (5); einde; tot (verzonden = Waar); Er moet een betere manier zijn om dit te doen; het lijkt verkeerd dat ik Sleep () gebruik. Is het mogelijk om een ??????gebeurtenishandler aan de TSimpleIPCClient.ServerRunning-functie toe te voegen?

  10. #40

    Quote Originally Posted by ;
    Is het mogelijk om een ??????gebeurtenishandler aan de TSimpleIPCClient.ServerRunning-functie toe te voegen?
    Ik heb TSimpleIPCIClient nog niet gebruikt. AFAIK het is ge�mplementeerd met named pipes en ik ken geen mechanismen om een ??????gebeurtenis te activeren wanneer de pijp tot stand komt, maar ik ben er niet helemaal zeker van. Maar u kunt van elke app een eigen IPC-server laten maken en ervoor zorgen dat ze elkaar onderling verbinden. Misschien kan dit leiden tot wat schoneregemakkelijkere code. BTW Lazarus 0.9.30 werd gisteren eindelijk vrijgegeven :-)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.