problem with FindWindow

[Jiri_P_]

Hallo

I'm not able to compile this code.

program SEC_TEST

use ifwin
implicit none

character*(256) title
integer :: hwnd

hwnd = findwindow(null, title)

end program SEC_TEST

I always obtain the next error message:

Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [FINDWINDOW]

Can anybody tell me why? I'm using IVF10.0.26 and VS2003.

Thanks Jiri

[g_f_thomas]

Making such an appeal for input for the original ivf samples code continues to cause the app to fail on Vista.

Gerry

[Steven_L_Intel1]

I got a chance to try the EXE I uploaded on a Vista 32 system. It worked normally - the prompt duly prompted, the dialog appeared in front of the console window and when I selected a file and clicked Open, the program displayed the filename and then exited. I could not reproduce the behavior Gerry describes.

[g_f_thomas]

You just did! You misunderstood what I reported.

Gerry

[Steven_L_Intel1]

Oh, you mean AFTER you close the Open File dialog box! I thought you were saying that the program didn't even prompt for input on Vista.

[g_f_thomas]

Read the record.

I hasten to point out to you that I tried your 'sample' on Vista as a courtesy. Treat it as such.

Till next time

Gerry

[Anonymous32]

Dear developers,

I am converting a CVF project to an IVF project.

When a subroutine is calling optzcopy fromIntelSP.for from CVF, there was this error:

Error: The type of the actual argument differs from the type of the dummy argument. [%VAL]

It is related to an argument that is defined as

!DECS ATTRIBUTES REFERENCE :: src

So I added this directive to the optzcopy interface to skip the check:

!DEC$ ATTRIBUTES NO_ARG_CHECK :: src

Adding above directive removes the previous Error message, but creates a new one:

Error: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [OPTZCOPY]

What does this new error message mean and how to remove it?

Thanks, Patricia

[Steven_L_Intel1]

Patricia,

We would need to see more information to be sure, such as the declaration of OPTZCOPY and the calls, but my guess is that adding the NO_ARG_CHECK directive is not what you wanted. OPTZCOPY is evidently a generic procedure and by adding NO_ARG_CHECK you told the compiler to not consider the data type of "src" when trying to resolve the generic, but that then made it ambiguous.

Show us the complete declaration of OPTZCOPY, the call you were making, and the declarations of the arguments in the call.

[Anonymous32]

Thanks Steve.

There are apparently inconsistencies in the calls that are using "src". Below are the details, could you give some hints how to remove both error messages ? Thanks!

1. The call to optzCopy that generates the 1st error :

Error: The type of the actual argument differs from the type of the dummy argument. [%VAL]

call doptzCopy(%val(M%YMl%nu),tapsN(1),M%YMl%nN)

M is a target with a self-defined type.

I added NO_ARG_CHECK directive.

2. That leads to the second error for another call:

call optzCopy(Y(1),YR(1),nSamples)

Error: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [OPTZCOPY]

Y is a real*8 pointer.

3. Here's the interface

interface

optzCopy subroutine sOptzCopy(src,dst,n) !DEC$ ATTRIBUTES STDCALL, ALIAS:'_nspsbCopy@12' :: sOptzCopy ! x86 systems !DEC$ ATTRIBUTES REFERENCE :: src !DEC$ ATTRIBUTES REFERENCE :: dst !DEC$ ATTRIBUTES VALUE :: n integer*4 :: n real*4 :: src,dst end subroutine sOptzCopy subroutine dOptzCopy(src,dst,n) !DEC$ ATTRIBUTES STDCALL, ALIAS:'_nspdbCopy@12' :: dOptzCopy ! x86 systems !DEC$ ATTRIBUTES REFERENCE :: src !DEC$ ATTRIBUTES REFERENCE :: dst !DEC$ ATTRIBUTES VALUE :: n integer*4 :: n real*8 :: src,dst end subroutine dOptzCopy module procedure dToSOptzCopy module procedure sToDOptzCopy module procedure i1OptzCopy end interface optzCopy

[Steven_L_Intel1]

NO_ARG_CHECK is definitely not appropriate here.

What is the datatype of M%YMl%nu? Why are you using %VAL?

[Anonymous32]

Data type of M%YMI%nu is

integer(int_ptr_kind()), it is passed from a Graphical interface to the Fortran routines,I thinkthat's why it is using %val.

[Steven_L_Intel1]

Ok, I get it. You can't do it that way, but you can do something like this:

real(4) tempsrcr4
real(8) tempsrcr8
pointer (p_tempsrc, tempsrcr4)
pointer (p_tempsrc, tempsrcr8)
...
p_tempsrc = M%YMI%ni

Now pass tempsrcr4 or tempsrcr8 rather than the %VAL() expression, depending on what you want the type to be.

What you're doing would likely work IF you were not using explicit interfaces.