🚀 go-pugleaf

W dniu 2018-01-30 o 17:51, Karol pisze:
> Nie do końca o to chodziło
> ponieważ
> try
>    //do something
>      raise Exception.Create('Something bad happened...');
>    except
>      on e: exception do
>      begin
>      //rollback a transaction or whatever i need to do here
>        MessageDlg('An error has occurred!' + #13#10 + e.Message + #13#10 
> + 'Here is the stack trace:' + #13#10 + e.StackTrace, mtError, [mbOK], 0);
>      end;  //except
>    end;  //try-except
> 
> e.StackTrace jest puste  ---> '' .

Dokładnie o to chodziło, a skoro stack jest pusty, to źle go używasz.

> W zasadzie potrzebuję uchwyt do załadowanej dll lub BPL.
> Pytanie wywoływana funkcja działa w "przestrzeni" w sensie modułu 
> uruchamianego bpl/dll czy EXE?
> Inaczej czy wyszukiwana funkcja działa jako część bpl/dll czy exe?
Tak by design, to jest tak...
dla BPL w kontekście EXE.
dla DLL w kontekście DLL.

> Potrzebuję to do tego.
> Plugin może poprosić o utworzenie tabeli w bazie ale nazwa tabeli musi 
> być poprzedzona nazwą modułu, aby nie było dostępu do tabel o 
> ograniczonym dostępie dla pluginów.
> A może można to lepiej zrealizować?
Tak, może i lepiej można... Ale, albo idziesz w stronę konwencji (to co 
opisałeś z nazwą modułu dla tabeli), ale to trzeba naprawdę dobrze 
zaprojektować.
Albo idziesz w stronę konfiguracji, czyli jakiś metadanych określających 
co jak i dlaczego.

A tak poza tym, to nie podoba mi się ten pomysł zakładania tabeli dla 
modułu przez moduł na podstawie jego nazwy...
To jest, imo, zakręcony temat, no chyba że te Twoje moduły nie posiadają 
zależności do innych modułów - to wtedy i tylko wtedy, może...

Ja to robię inaczej; konfiguracja systemu jest elastyczna, ale struktura 
bazy danych jest dostarczona cała w pełnej konfiguracji.
Jeżeli dany moduł nie istnieje w danej konfiguracji, to po prostu nie 
używa jakiś tam obiektów w bazie danych.
A że baza ma tabele, które są puste i nieużywane?
I co z tego?

-- 
wloochacz