Using putStrLn/printf from DLL in GUI application
How many times you tried to use putStrLn from Haskell or printf from C when you are building DLL loaded in GUI application? This simply doesn't work because by default the GUI application doesn't have console window. The solution is to use allocConsole/freeConsole from the attached library. Example: do allocConsole ..... ..... putStrLn "Hello, world!" ..... ..... freeConsole This could be a good addition to the standard Win32 library if someone take care to integrate it. Cheers, Krasimir
Am Freitag, 1. Dezember 2006 21:37 schrieb Krasimir Angelov:
[...] do allocConsole ..... ..... putStrLn "Hello, world!" ..... ..... freeConsole [...]
Having explicit alloc/free pairs can lead to resource leaks in the presence of exceptions. Simple solution: Merge both parts into a single function, using "bracket" or friends internally: withConsole $ do ... putStrLn "I'm exception safe! :-)" ... Cheers, S.
withConsole doesn't make much sense. The meaning of allocConsole/freeConsole is more like showConsole/hideConsole. You may want to show the console from DllMain when the dll is loaded and to hide it when it is unloaded. You can't do this with withConsole. Cheers, Krasimir On 12/2/06, Sven Panne <sven.panne@aedion.de> wrote:
Am Freitag, 1. Dezember 2006 21:37 schrieb Krasimir Angelov:
[...] do allocConsole ..... ..... putStrLn "Hello, world!" ..... ..... freeConsole [...]
Having explicit alloc/free pairs can lead to resource leaks in the presence of exceptions. Simple solution: Merge both parts into a single function, using "bracket" or friends internally:
withConsole $ do ... putStrLn "I'm exception safe! :-)" ...
Cheers, S.
Am Sonntag, 3. Dezember 2006 12:07 schrieb Krasimir Angelov:
withConsole doesn't make much sense. The meaning of allocConsole/freeConsole is more like showConsole/hideConsole. You may want to show the console from DllMain when the dll is loaded and to hide it when it is unloaded. You can't do this with withConsole.
OK, then I misunderstood the meaning of those functions and simply demonstrated my virtually non-existent knowledge of the Win32 API details. ;-) I had a quick look into MSDN, and your proposal seems to make sense then. Nevertheless, a strange naming, but of course it is good to choose the same names in Haskell as in C... Cheers, S.
participants (2)
-
Krasimir Angelov -
Sven Panne