BTW: heb je mijn thread al gezien over het maken van dll's met FPCLazarus?
https://www.aforexa.com/general-fore...oning-egy.htmlIk zou een hoofdstuk moeten toevoegen dat is gewijd aan globale variabelen, hoe je ze kunt vermijden en hoe je ze kunt gebruiken als dat echt nodig is.
In de regel worden globale vars in uw DLL gemaakt op het moment dat de DLL wordt geladen (eerste aanroep van de DLL). en veranderd door ALLE toegang. Lokale variabelen binnen elke functie zijn toegestaan ??????wanneer de functie wordt aangeroepen en verwijzingen naar deze worden opgeslagen op de stapel, ze worden alleen benaderd door de functieaanroep waarmee ze zijn gemaakt en worden vernietigd wanneer de functie wordt afgesloten. Het probleem dat je hebt is een Multi Threading probleem EG: - E1 en E2 zijn 2 EA's die elk in een andere thread lopen. D1 uw DLL F1 uw DLL-functie ingevoegde code/uw DLL-code/Global Var int x; ongeldig F1 (); {int y;/lokale var x = 1000; while (xgt; 0) {y = 2000; while (ygt; 0) {y--;} x--; }} Dus als het loopt, zou het volgende kunnen en zal gebeuren: E1 roept F1 aan en een nieuwe 'temp' var Y wordt aangemaakt. Het stopt dan halverwege de functie omdat het besturingssysteem aangeeft dat het tijdsbestek voorbij is. Alles werkt goed. Als E2 niet bestond, zouden er helemaal geen problemen zijn. E2 roept nu F1 aan en er wordt een nieuwe 'temp' var Y aangemaakt. F1 stelt onmiddellijk x in op 1000 ... U hebt nu de oproep van E1 naar de functie verbroken omdat de globale variabele is veranderd en wanneer E1 de processor terug krijgt, zal int x anders zijn dan toen hij ophield. Natuurlijk zal E1 het niet weten, of hier om geven. Je kunt dit eenvoudig oplossen zonder OOP, je moet er alleen van bewust zijn dat je dezelfde functie (s) vanuit meerdere threads oproept, dus je moet thread safe zijn. Of je nu met of zonder OOP bent, je moet een manier hebben om een ??????afzonderlijke int X aan elke EA toe te kennen. Vandaar de noodzaak om een ??????Init-functie te bieden om een ??????afzonderlijke 'bank' van globale variabelen aan elke EA toe te wijzen. In het bovenstaande voorbeeld zou dit gemakkelijk kunnen worden bereikt door van Int X een array met geschikte afmetingen te maken en door initdeinit-functies te voorzien om een ??????array-dimensie-element toe te wijzen aan elke unieke beller aan de init-functie. BIJVOORBEELD E1 int myID = DLLinit ('GBPJPY');/geeft 1 F1 (myID) terug;/nu kan F1 MyID gebruiken om naar de juiste X var in de globale array te verwijzen. E2 int myID = DLLinit ('EURUSD');/retourneert 1 OOP is vaak een veel elegantere manier om dit probleem te ondervangen, maar werkt alleen als u het probleem begrijpt en het vervolgens correct codeert. Met OOP zou je een nieuw object (een voor elke EA) willen maken wanneer ze een DLL-init-functie aanroepen. Dit zou alleen werken als u een afzonderlijke reeks 'globale' variabelen inkapselt binnen elk nieuw object.
7bit: ik heb de code veranderd om die paar globale variabelen niet te hebben, ik had ze pas opgemerkt toen ik de code geplakt had, ook met je bevestiging dat ze volhouden tussen de gesprekken is volkomen logisch waarom het deed wat het was . ik zal je laten weten hoe ik verder ga met het testen van de demo. ik zal uw artikel nu bekijken, ik heb het misschien gelezen, u leest tegenwoordig zoveel! nogmaals bedankt
Rangebound: Bedankt voor uw bericht, ik zie het probleem dat ik fout ging was dat ik veronderstelde dat elke belasting van een EA een afzonderlijk exemplaar van het DLL-bestand zou laden, netjes gescheiden van andere oproepen die mogelijk worden uitgevoerd. Helemaal eens met je voorbeeld. Grappig genoeg wetende dat dit me een oplossing heeft geboden voor een ander probleem dat ik heb gehad, was het antwoord er altijd al. Bedankt voor je hulp
Ik wil ook graag bedanken! tot 7bit en rangebound voor hun hulp hier. Het was erg behulpzaam. Ik gebruik Delphi 2009 (Object Pascal) om mijn DLL's te schrijven. Met behulp van het advies in deze thread en ook deze, heb ik alle crashes ge�limineerd door alle globale variabelen naar een klasse te verplaatsen en een aanwijzer naar het object tussen MT4 en de DLL door te geven. Hiermee zijn eventuele geheugenbotsingen opgelost. Het lijkt er echter op dat er nog steeds iets is dat ik niet begrijp. Om ALLE crashen te voorkomen, moest ik een TCriticalSection gebruiken om ervoor te zorgen dat slechts ��n grafiek tegelijk toegang tot de DLL had. Bijvoorbeeld: ingevoegde code/Delphi (Object Pascal) DLL-code: var csTick: TCriticalSection; functie DLLGet: Boolean; begin csTick.Enter; Resultaat: = Waar; einde; procedure DLLFree; begin csTick.Leave; einde; initialisatie csTick: = TCriticalSection.Create; finalisatie csTick.Free; Code ingevoegd/EA-code: #import MyLogic.dll bool DLLGet (); ongeldig DLLFree (); #import int init () {DLLGet (); int iPointer = DLLGetNewObject (Symbol ()); ... Andere initialisatie ... DLLFree (); return (0); } int start () {static int iPrevOrderCount = 0; DLLGet (); ... meerdere DLL-functieaanroepen ... DLLFree (); return (0); } Nogmaals, ik heb geen globale vars in de DLL; alles (behalve het TCriticalSection-object) is ingepakt in de klasse en de klasseverwijzing wordt bij elke functieaanroep aan de DLL doorgegeven. Maar ik krijg nog steeds een soort van botsingcorruptie omdat ik de thread-semafoor (TCriticalSection) moet gebruiken om het goed te laten werken. Dit is de reden dat ik dit allemaal meeneem. Er is nog steeds een klein probleempje: als deinit () wordt opgeroepen voor een grafiek, breekt MT4 onmiddellijk uit de start () -functie, wat soms betekent dat DLLFree () niet wordt aangeroepen en dat alle andere diagrammen zijn vergrendeld uit de DLL. Dus kort samengevat is mijn vraag: waarom moet ik de TCriticalSection-semafoor gebruiken? Als alles in een klas zit, welke andere botsingen kunnen er dan zijn? Dank je!
Mijn fout
. Ik vond een globale var in een opgenomen eenheid. Ik heb die var verwijderd en alles is nu in orde - zonder de noodzaak voor de semaforen! Nogmaals, bedankt voor je hulp.
Voor de meeste DLL's zou je geen kritische secties hoeven te gebruiken, dit wijst dus op een andere onderliggende coderingskwestie, die een van de vele dingen zou kunnen zijn. Het beste wat je zou kunnen doen is .... Knip code uit je DLL totdat je de meest elementaire DLL hebt die nog steeds crasht. Plaats dan de bron hier en ik zal een kijkje nemen. Met in gedachten dat je niet aangeeft wanneer een crash optreedt ... Als je niet wilt dat die route naar beneden gaat, zijn mijn beste gissingen: 1) Als je EA een deinitInit doet, dan kan je DLL proberen een tweede object te maken voor de hetzelfde valutapaar. Heb je een val gecodeerd om dupliion te stoppen? Ga er niet vanuit dat uw DLL gegarandeerd een DeInit-oproep ontvangt. U moet controleren op dupliion van initialisaties van dezelfde valuta. 2) Is DLL het opslaan van de aanwijzers en het beheren van de vernietiging van deze objecten?
Bedankt Rangebound! Alles werkt nu goed, zonder crashes of geheugenlekken, maar je bericht werpt een paar vragen op:
Zoals ik het heb geschreven, als deinit () niet wordt aangeroepen, zal het object niet worden vrijgegeven. Maar afgezien van het geheugenlek dat niet zou moeten crashen omdat het tweede object een nieuwe geheugenloion heeft, klopt dat?Originally Posted by ;
Normaal zou ik een TThreadList (een thread-blocking lijst van pointers) in de DLL gebruiken om zoiets te doen - is er een andere manier? Met andere woorden, hoe zou ik de wijzers in de DLL moeten opslaan zonder een globale var of een blokkeringsmechanisme te gebruiken? Dit is erg nuttig - bedankt voor uw inbreng.
Bewaar de pointers in de DLL helemaal niet. Cast ze in 32-bits gehele getallen, sla ze op in de EA, behandel ze als resource-handles van een soort, en geef ze door als parameters naar wrapper-functies in de dll (die ze dan terug zullen werpen, derefereren en dan de eigenlijke methode noemen van de objectinstantie). Ik doe dit in mijn Python-binding. Alle Python-objecten in de python26.dll zijn eigenlijk verwijzingen, maar ik kan ze eenvoudig behandelen als gehele getallen die door de mql-code moeten worden gebruikt. Al mijn python API-wrapper-functies die een pointer naar een python-object nodig hebben, accepteren eenvoudigweg een geheel getal, voor de MQL-code zijn alle python-objecten slechts integer-handles.
Yup, dat is precies wat ik aan het doen ben, maar RangeBound maakte zich zorgen over het feit dat het object niet werd vrijgegeven omdat DeInit () mogelijk niet werd gebeld en stelde voor dat ik een lijst met verwijzingen opsloeg in het DLL-bestand zodat het het geheugen kon beheren.
Posting Permissions
Reply With Quote