0

I am wondering a situation during the program execution when the user (beginner programers ones) could implements under an event notification, for example: 

TNotifySomething : procedure (const param: TObject) of object;

1 - This event may be implemented by a Dll? I have to publish somehow?
2 - May I pass by reference the objects instantiated during the program execution to the dll method?
3 - In a multithreaded environment, if I call the event(defined in the dll) by 2 or more threads, it will cause me any troubles, like access violations ?
4 - Somebody knows a good book or paper where I can read about it?

P.S : This can be done in Delphi 6?

EProgrammerNotFound
  • 2,403
  • 4
  • 28
  • 59

1 Answers1

1

1) no. Google for DLL vs BPL. This topic is recurring since 1997. BPLs are for Pascal. DLL are for Windows. There is no objects in Windows. But there are COM interfaces (IUnknown with COM-defined types, that are sup-set of your Pascal types, event callbacks are not there)

You can also try "can JCL except_stack_list work for dll? " thread at http://newsportal.delphi-jedi.org/thread_frameset.php?group=jedi.jcl

2) by means of IUnkown and COM-standardized data types. Other than that you override compiler's type safety which means you should implement and provide your own pascal-to-binary safety layer.

3) Depends on your code, both callee and caller. If both are reentrable, then they are. If some one is not - it would trigger an error.

4) depends what you want to achive.

if you want to get taste of DLLs: any book of assembler, then Delphi manuals about implementing procedures in asm instead of Pascal, especially about binary representation of all those datatypes in different Delphi versions. If you deny Delphi-standard type safety, then you need to provide your own one.

if you want to get taste of COM, then any book about COM and Delphi manuals about implementing and consuming COM objects.

if you want to get taste of BPLs - then read Delphi manuals about Runtime Packages. They are 1st class citizens in Delphi and extra books are but optional.

Arioch 'The
  • 15,799
  • 35
  • 62
  • I guess the most reusable could be implemented using COM objects. There is a way I provide by COM Objects an interface readable for DLL and some application? I actually don't need objects I just need a way to access then... what i need is public methods to be called in at a given time – EProgrammerNotFound Mar 18 '13 at 11:30
  • 1st of all - why cannot u use BPL ? If you going to use your objects in non-Delphi languages, then Delphi TObject would not be of any use at all (different Delph iversions are different languages). – Arioch 'The Mar 18 '13 at 11:34
  • Then, if you only need public code entry points, then forget about objects at all - do public procedures/functions. But they need to be standard windows functions: that means `stdcall` calling conventions and all parameters better be integer, pointer (including pointer to letters - `PAnsiChar` - as a way to pass strings, after memory management responsibility set) or float (single or double). Again, for use inside Delphi that may go as plain TurboPascal units within BPL (then you can drop out `stdcall` and pass any pascal datatype including string). – Arioch 'The Mar 18 '13 at 11:38
  • More details read in your Delphi manual about creating DLLs and exp[orting functions from it and which simple datatypes are allowed. For COM servers you'd have to implement standard entry points like mentioned at http://ccc.panitzco.com/mpanitz/com_tutorial/comserverincinproc.html#Create%20DLL%20Entry%20Points Read Delphi manual about DLL, about implemenmting COM Server in Delphi and do buy and read some good book about COM design and use. – Arioch 'The Mar 18 '13 at 11:42
  • COM is most flexible, but at the same time most complex - COM is large framework on its own. You should really think what exactly your requirements are. There is no point in shooting sparrows with a mortar. Google's second link is http://stackoverflow.com/questions/1192734 - i think you'd read it as well as other top Google results. This topic is very basic and long discussedthrough and through years and years ago. – Arioch 'The Mar 18 '13 at 11:43
  • Just to be clear, I will use the DLL to program public funtions to be called by the program A. The program A run in 2 or more threads that's why I need to concern about synchronism, those dll's must see program A objects, at least their properties. – EProgrammerNotFound Mar 18 '13 at 11:48
  • The final objective is avoid using interpreter in the program A – EProgrammerNotFound Mar 18 '13 at 11:50
  • re-write program A so it would use BPLs. Those classes that "those dll's must see program A objects, at least their properties" should be declared in BPLs that both EXE and DLL would use. Read the discussion about plugin systems. Another option would require YOU to implement some kind of RPC and property marshalling between DLL and EXE. You would need to make a generic interface for accessing any class property, like serializing class to JSON string or some smarter approach. That is VERY dependent upon the essence of the program. Perhaps you'd still use scripting lib at least for marshalling – Arioch 'The Mar 18 '13 at 11:54
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/26377/discussion-between-matheus-freitas-and-arioch-the) – EProgrammerNotFound Mar 18 '13 at 12:06