HMGforum.com

Hola :
Estoy probando un sistema realizado con HMG.3.2 que utiliza la funcion CALLDLL con la nueva version y no funciona .
Para probar intento con los ejemplos de la carpeta DLL de SAMPLES y tampoco funcionan .

Con HMG.3.2 tanto el sistema como los ejemplos funcionan sin problemas

Uso Win7 32 bits

Saludos cordiales
Mario Mansilla

Thank you Mario for reporting. This is really happing at version 3.4.0 and not happen with previous HMG versions.
I've tested in 3.2 and 3.3.1 versions and works properlly.

I did not found the solution I hope to be solved by Claudio otherwise I could think C Preprocessor changing ?

Also at Harbour seems not have been changed (at least not declared at Harbour's ChangeLog)

Let's wait Claudio's opinion

Pablo César wrote:Also at Harbour seems not have been changed (at least not declared at Harbour's ChangeLog)

Let's wait Claudio's opinion

I think I was wrong when I said that. Reading carefully Harbour's ChangeLog there are some changing regarding GetProcAddress and there is function call at HB_DynaCall for DYNACALL1.
So probably some internal Harbour's routines was modified...

CALLDLL32 This function has originated by Minigui and Viktor Szakats adapted to Harbour in hbmisc contrib on 2010-05-27.

I guess some changes happen in MinGW C Preprocessor, because at HMG 3.4.0 is not working properly...

Also I guess the main problem could it be when was modified GetProcAddress function to adjust for ANSI/UNICODE or 32/64bits proposes. ( See at Harbour's ChangeLog at 2014-02-01 09:11 UTC+0100 Przemyslaw Czerpak )

So, in that way, I will check if we have to fix our library changing GetProcAddress by GetProcAddressW or GetProcAddressA according when it been in ANSI or UNICODE. But this it should be review when at updated Harbour version in HMG pack.

Hi Pablo,

The main problem with minigui are the following two:
First, minigui, unfortunately, did not keep a close touch with parent project (Harbour)
regarding the windows API. In Harbour we have the hbwin and some other libraries
(f.e. hbmisc, hbxpp et.c.). Those libraries are based on very robust and heavily tested
pieces of code. Now, many of the hbwin functions there exist in minigui but there are
implemented by their own (and in some cases, very aged) code.
If you'd ask me which one of the different implementations (Harbour's or minigui's) I would trust and would prefer,
well I'll let you guess..

Second, minigui (both variants, official and extended) suffers by the well known
(I'd say inevitable) "desease": Plenty of "workarounds" and circumstantial fixes.

Saying this, I don't try to eliminate or undervalue the tremendous work that has been done
by the main minigui developers and all the remarkable contributors. I'm just spotting a fact.
Minigui is an exceptional and very succesful GUI library for Harbour compiler.
I like it and I do use it for a long time.

What I'm trying to note, is that when a problem arises, it is good to try to isolate it in accordance
to the parent project (Harbour) by seeking solutions that do not conflict or do not ignore relevant
solutions already implemented in Harbour.
That said, I think that Minigui needs a refreshing clearance of those "its own" API functions
and replace with those which there exist in Harbour with similar names.

As a I have mentioned, CallDll32 of minigui is (at least according to my tests) broken!
The same probably apply (not tested, though) for LoadLibrary/FreeLibrary/GetProcAddress et.c. functions.
It would be a good move to have those functions replaced by the wapi_* equivalent functions
found into hbwin library.

I know that's not an easy task, not to mention that it may break compatibility with existent code.
But again, trying to fix a not so good/outdated or perhaps buggy code, which conflicts with Harbour,
doesn't seem an optimum choice either.
Maybe the suggested replacement could be done by a step-by-step process.

That's my two cents.

best regards,

---
Pete

Hi Pete,

Your opinions are quite always hard to be told, but I believe we always learn and improve our concepts, specially when the true is coming to clear.

I was waiting an official opinion before I answering this. So I will express my POV which is not to be considered as official politics in HMG.

I can agree with you in parts. When you say Minigui is not concerned to keep close in touch with parent project (Harbour) regarding Windows API is quite most unfair because HMG is always concerned to keep most as possible the compatibility with Windows API. Many of some non-conventional controls are not approved because is not considered cannonical aware for API in HMG.
What is happining now recently is at this last HMG version (3.4.0) and as any software with new release is subjected to make post corrections/adjustment specially in our case as Harbour is starting work in UNICODE as we have already started. And I said that I considered unfair your most important POV is because these CALLDLL32(), HB_DYNACALL1(), STRPTR(), PTRSTR(), UNLOADALLDLL() are Minigui creation and it has been served as referance for Harbour. I believe these functions were not exist before in Harbour, right ?.
What I have not seen clearly is why Viktor has used same functions names and what did not kept retrocompatibility at these lasted Harbour versions (nearly 3.2.0dev r1501091819 with HMG 3.4.0). But this is not HMG fault, IMHO.

I also believe all this process of fixing code, API adaptations can occurred at any language and making participation of all this process is healthly. But we can not say is a problem. Problem is IMHO when there is a radical solutions or non solution at all.

I know you do not set out to debunk our work, either because all of us that we contribute to improve our tool and we have to adapt ourselves, in first with the evolution of OS (API changes for example), changes in the Harbour and improvements in Widgets. We can not think that everything is perfect and we seek not closely follow the father's Harbour project.
Right here on the forum, we have another section that deals exclusively with the development and changes in Harbour, Harbour ChangeLog is always publicated when is directly affects HMG (but in this case there is no register about this radical change) and has many other graphical tools that are used procedures such as the CallDll32() with other names and not so for that they are considered better or worse.

I really thank you for your indications, I was trying that but with no success upto now. When you mentioned I got a test and works successfully by removing in my copy of HMG all these functions, letting Harbour (with same names) to do this job.
I do not planned to add wapi_* because is considere discontinued and to see what it be comes we have to remove imediatly.

I repeat, thank you to advice us you and Mario Mansilla which started this topic.

Now we should wait what HMG Development Team + Founder which it will be their decision for next release. As I said, the main important is to detect, isulated the malfunction and to bring a solution or posible solution.

Thank you very much Pete + Mario !

Provisional solution (unofficial) for the current version HMG 3.4.0:

To edit C:\hmg.3.4.0\SOURCE\h_controlmisc.prg and C:\hmg.3.4.0\SOURCE\c_controlmisc.c and execute buildlib.bat.
This is what I've done and worked perfectly.

I've forgot to say that at HMG DLLs samples, after using Harbour's functions regarding CallDll32, samples also should be corrected too at:

At C:\hmg.3.4.0\SAMPLES\Controls\DLL\DLL_1\demo.prg:
MENUITEM 'Test' ACTION CallDll32( "sndPlaySoundA", "WINMM.DLL" , "sample.wav", 0 )

This is because this last correction made in Harbour, where function will work ever in ANSI.

Pablo César wrote:Provisional solution (unofficial) for the current version HMG 3.4.0:

To edit C:\hmg.3.4.0\SOURCE\h_controlmisc.prg and C:\hmg.3.4.0\SOURCE\c_controlmisc.c and execute buildlib.bat.

Screen4.png

Screen5.png

This is what I've done and worked perfectly.

Done, thanks Pablo.

Hi Pablo,

Pablo César wrote:Hi Pete,
Your opinions are quite always hard to be told, but I believe we always learn and improve our concepts, specially when the true is coming to clear

I'm not sure what exactly you mean here, but anyway..

I can agree with you in parts. When you say Minigui is not concerned to keep close in touch with parent project (Harbour) regarding Windows API is quite most unfair <snip>

You know, technical points of view (like those I wrote in my previous post) can be either correct or wrong and yet it 's fairly easy to prove their correctness or incorrectness. On the other hand, moral judgements, like "unfair" or whatever, it's quite hard to be measured. I believe that we might make our lifes simpler if we treat technical subjects without emotional or moralistic interferences.

I really thank you for your indications, I was trying that but with no success upto now. When you mentioned I got a test and works successfully by removing in my copy of HMG all these functions, letting Harbour (with same names) to do this job.

Glad to see, that you've found and you've removed, as hinted, the erroneous piece of code out of contromisc.* modules, solving the problem in question. Good cleanup! -yet much more is left to be done. Exposing and discussing about them, is what we call "maintenace" and it's a good/healthy thing.

I do not planned to add wapi_* because is considere discontinued and to see what it be comes we have to remove imediatly.

Why do you say that? AFAIK, hbwin contrib library is part of harbour distribution. never heard anything about "discontinuation"...


P.S. These guys into harbour's core-developers team, have done extremely good work and is pitty if we don't grasp the chance to benefit out of it by synchronizing our code.

best regards

---
Pete