Using LoadIcon and CreateWindowEx in Vers6.6

[Intel_C_Intel]

I am using some Windows API calls in our code that that compiles and runs fine in CVF Version 6.5. However, when I upgraded to the downloadable version of 6.6, I get two errors related to the commands "LoadIcon" and "CreateWindowEX". I have reviewed the release notes and online help without success. I have tried using several other libraries. Can anyone point me in the right direction? The error messages are below:

M:TRNSYS15TypesType66.for(165) : Error: There is no matching specific function for this generic function reference. [LOADICON]
wc%hIcon = LoadIcon(trnInstance, LOC(lpszIconName))
--------------------^
M:TRNSYS15TypesType66.for(174) : Error: There is no matching specific function for this generic function reference. [CREATEWINDOWEX]
trnhwnd = CreateWindowEx(0,
-------------------^
Error executing df.exe.

Thanks,
Nate Blair n8blair@hotmail.com

[wkramer]

I also had some problems with CreateWindowEx when upgrading to 6.6
As second parameter I used TOOLTIPS_CLASS which was not defined in the updated DFWINTY. I had to use TOOLTIPS_CLASSA. This problem is solved in upgrade 6.6A (for testing available from this forum).
The error message means that one of your parameters to the function is of the wrong type.
You have to look in the .DF98Include folder in user32.f90 for the types of the parameters you have to pass to LoadIcon, but I expect that the problem is solved in 6.6A anyway.

Walter Kramer

[Steven_L_Intel1]

We did have a compiler problem that could result in this error. Try the final 6.6A update which is here.

Steve

[Intel_C_Intel]

Question looks like incorrect/incomplete, because there are no description of trnInstance variable, trnhwnd variable and call string for CreateWindowEx looks like incomplete. I could suppose, that this program has no INTEGER*4 type declaration for trnInstance, and author has these two error because of trnInstance using in BOTH operators. If CVF 6.6 can catch such thin details, then, it might be, it'not necessary to remove this feature in 6.6A version? ( This is the question for Steve Lionel, of course).

Vladimir V.Vasilchenko
Fortran Programmers Club
http://www.donpac.ru/usr/golub/fortran/
http://fortran-windows.tripod.com

[Steven_L_Intel1]

Vladimir,

I don't quite understand your question. CVF will catch mismatches between the call and the interface. The problem here is that when we retranslated the Win32 API declarations for 6.6, some things didn't get correctly translated. Many of these were fixed in 6.6A, more will get fixed in the future.

Steve

[Intel_C_Intel]

Steve,
OK, let's try again. We started with Nate Blair question about the problems in LoadIcon and CreateWindowEx calls. In your previous answer for her you wrote about possible bugs/problems in your compiler. But, from my side of view, she made the mistake - it seems to me, that there was no explicit declaration INTEGER*4 trnInstance in her program. This parameter is used in both operators she asked about, so she has two error messages. From my side of view, it's good feature of CVF, because we can hope on correct work for the case of overloading operations, when compiler must recognize function/operation on the base of provided parameters types. But your previous message looks like wish to eliminate this good feature in next 6.6A upgrade... You're the boss, of course, but such correction looks like unnecessary, either? :)))
If you want only to declare about problems/bugs in CVF - no problem, I'm agree - I already have collection of bugs/mistmatchings from all versions of your compiler. Like all users of CVF, I also hope that their number will decrease with time. But for the case of Nate's question, I don't see the reason for compiler correction.
Hope I explained my previous question...

Vladimir V.Vasilchenko
Rostov-on-Don
Russia
http://www.donpac.ru/usr/golub/fortran/
http://fortran-windows.tripod.com

[Steven_L_Intel1]

I can't tell, without seeing the whole code, what Nate's problem is. (Nate is most likely a "he", by the way.) The bug I referred to was simply some missing PARAMETER constants in DFWINTY. I know you have said that you have a collection of CVF bugs, but as you haven't reported any of these to us, there's not much I can say about it.

The Win32 declarations in CVF 6.6 are much improved (and more comprehensive) than in past versions, as they are program-translated from the latest Visual C declarations, but some things didn't translate properly so we continue to improve the process (and the declarations). If anyone has issues with the Win32 declarations, please send us examples at vf-support@compaq.com

Steve

[Intel_C_Intel]

Steve,
I think, that simple way for you was to say "Sorry, I only announced the appearance of next ( maybe final :)) ) 6.6A upgrade for CVF...". Of course, I'm not so experienced in English, so I'm sorry, if I made the mistake in name interpretation - "Nate" looks similar to "Nata" in Russian - classic russian name for woman. But, concerning your answer, when I see "...I can't tell, without seeing the whole code, what Nate's problem is...", the question arises - do you know, that you wrote the answer on the question from CVF user? And, if "...The bug I referred to was simply some missing PARAMETER constants in DFWINTY...", then you could publish this in separate message for all users/visitors of forum. Steve, it seems, that you criticize hard your compiler. :)) From my side of view "missing PARAMETER" means "incomplete, but developing...", but incorrect interface is really "bug". Steve, I see also, that you're not so experienced FORTRAN programmer under Windows, so I would like to provide users my own remark to your last message - "Thinking about the Nate's problems, ignore, please, Steve's sentences about missing PARAMETER(s) in CVF modules, because your attempts to find parameters "trnInstance" and "lpszIconName" somewhere in MS C/C++ headers will look like absolutely meaningless business".
And about "...I know you have said that you have a collection of CVF bugs, but as you haven't reported any of these to us, there's not much I can say about it..." As I remember, my first question about serious problems in DVF 6.0 installation had the trivial answer from you with advices "to be more accurate during installation :)(". I found one man from your development team, who knew about this DVF bug and he helped me with receiving the correct version of some dll-file. During some time I sent some samples from my "collection" to your development team, but I found that some of your guys forgot to say at least "thanks for help". And I stopped this meaningless business, of course.. Also, some time ago we discussed strange CVF behavior for operations, for example, a++++b,c+-+--+d in comp.lang.fortran newsgroup. Short memory, either?

Vladimir V.Vasilchenko

Fortran Programmers Club

http://www.donpac.ru/usr/golub/fortran/

[Steven_L_Intel1]

Vladimir,

My response about the missing PARAMETER constants was in reference to Walter Kramer's message. I don't know what caused Nate's problem.

Steve

[Intel_C_Intel]

Steve,
I think you need to rebiuld your site/forum, to make its content more clear. Standard tree-like structure (Google, newsgroups in MS Outlook Express) looks like more appropriate and could make your forum more clear for users/readers/participants.

Vladimir V.Vasilchenko

http://www.donpac.ru/usr/golub/fortran/

http://fortran-windows.tripod.com