Xeffort issues

[Neels]

With the latest compiler updates on the latest Windows 10 machines I get the following:

1. The main program does not start executing after closing the dialog box using the original lib,
2. Recompiling Xeffort with the latest compiler it does now start the main program but,
3. Now the Xmessagebox appears but has no text displayed nor any buttons or icons.

Are there other users of Xeffort that can help or maybe Steve can have a look?

[Steve_Lionel]

I have spent a LOT of time on this and have several negative results. It isn't a change in the modules, as if I compile Xeffort with the new compiler and old modules, the problem is still there. The exact same dialog template is being sent to Windows in both cases. Other than the dialog title/caption, none of the controls appear, and I can't figure out why.

[Neels]

Thank you Steve, any suggestions on how to proceed? Anything I can take a look at or do?

[Steve_Lionel]

I can't think of anything. There are a few more things I want to try.

[Neels]

As a temporary workaround I created a dialog box to use as a message box . Meanwhile I am trying to understand what the coding does but it is a very steep learning curve. I read explanations but the words used makes no sense to a non-software person (well to me!). Can somebody explain in a simplistic way what the following code does (it is from XFTDialog.f90, around line 452):

!Dlgtemplate
iSize = SIZEOF(DT)/2
iDt(iPos:iPos+iSize-1) = TRANSFER(DT, i2, iSize)
iPos = iPos+iSize-1

The biggest problem I have is with "TRANSFER" and why it is required.

[Steve_Lionel]

That I can help with. This code is putting together the input for DialogBoxIndirectParam, which is a sequence of DLGTEMPLATE, DLGITEMTEMPLATE and other structures that define a dialog box. The code put together in local variable DT the DLGTEMPLATE structure and now it is moving it to the front of array of INTEGER(2) values it allocated (GlobalAlloc) earlier. iDt is a pointer (Cray pointer) to this array and iPos keeps track of where the code is in that array as it fills in pieces of the rest of the structure. The TRANSFER is a way to do a byte copy without violating language rules for type and shape.

[Neels]

Thanks Steve, that makes sense. Is there a way to print out the complete structure to compare between the two compiler versions?

[Steve_Lionel]

Yes, and I did that as part of my debugging. The way I did it was to open a memory window and enter the value of lpdt (the address of the integer(2) idt array.) Make sure you're only comparing the 0:ipos elements at the time of the call to DialogBoxIndirectParam. You can select a range in the memory window and print it. I did not spot any difference.

[Neels]

Not sure if this will help but I added write statements after each iPos position and then wrote out the content using the following:

write(50,*)'iPos1 = ',iPos
write(50,*)iDt(iPosOld+1:iPos)
iPosOld = iPos

iPos1 is after the first value assigned, iPos2 after the second update etc. Some values are not used as they are in If loops.

The results between the two compilers are listed in the two attached files. The JPG shows the differences using BeyondCompare.

[Steve_Lionel]

Interesting - I'll take a look at this later.

[Neels]

It seems that when a large integer is split into two byte copies by TRANSFER it does not work the same as in the old and new compiled versions. This is the piece of code that gives the difference:

!=====================================================================
!Appends an integer(4) into a DLGTEMPLATE stream used by XMessageBox
INTEGER FUNCTION PXPutInt4(iDt, iPos, i4) RESULT(newPos)

INTEGER(2), INTENT(INOUT)::      iDt(0:*)
INTEGER, INTENT(IN)::            iPos
INTEGER, INTENT(IN)::            i4

write(50,*)
write(50,*)'i4 = ',i4,' iDt(1) = ',iDt(1),' iPos = ',iPos

iDt(iPos:iPos+1) = TRANSFER(i4, iDt(1), 2)

write(50,*)'iDt(iPos:iPos+1) = ',iDt(iPos:iPos+1)
newPos = iPos+2

END FUNCTION PXPutInt4

!=====================================================================

The write statements are my own. The attached files are updates from before, with the i4 write statements as shown in the code above. Also, at the end I write the complete iDt(0:iPos).

[Steve_Lionel]

Yes, indeed, you have found a bug in the compiler. Congratulations! I suspect this was introduced when the compiler was updated to account for an interpretation to F2008 regarding TRANSFER. An easy fix is to remove the (1) in iDt(1) and change the declaration of iDt to (0:1).

I will report this to Intel. (Issue ID is 03894709.)

[Steve_Lionel]

FWIW, I tested this fix and it corrects the Xeffort issue.

[Neels]

Thank you Steve for spending the time and effort on this. I tested the fix and it now works!

[joerg_kuthe]

Just a comment regarding #25. I think I found a bug in XMessageBox (XFTDialog.f90), and I fixed that:

!Dlgtemplate
iSize = SIZEOF(DT)/2
iDt(iPos:iPos+iSize-1) = TRANSFER(DT, i2, iSize)
!<qt2018-12-07#: it appears that the following PXPutInt2 overwrites the last
!                2 bytes of the previous copied DT
!#iPos = iPos+iSize-1
iPos = iPos+iSize
!>
!Menu/Class
iPos = PXPutInt2(iDt, iPos, (/0_2,0_2/))

That works on my PC (Win7, compiled with 15.0.4.221 [IA-32]), so the dialog is displayed (before I got an error 1407, window class not found, after DialogBoxIndirectParam was called).

I haven't read the comments regarding the TRANSFER function in detail, but it might be that this is working correctly. At least it does with 15.0.4.221 [IA-32]), I think.

Joerg

[Steve_Lionel]

I didn't see a problem like that. I remember staring at that code to understand what it was doing, At the time I didn't think it was wrong, but on second look I agree with you. Compare this with the code in PxPutInt2:

iDt(iPos:iPos+SIZE(i2)-1) = i2
newPos = iPos+SIZE(i2)

[Neels]

If I make that change I get an exception at the following line:

XMessageBox = DialogBoxIndirectParam(hInst, lpDt, hWnd, LOC(PXMessageBoxDlgProc), idButton(iDefButton))

[Steve_Lionel]

I agree that this has me puzzled. I have to think that the original code is correct, but I don't understand how.

[joerg_kuthe]

I am following this thread a bit, and thought that I post my xftdialog.f90 such that all of you have the same code basis. On my PC now I have at least 3 versions of the XEffort source code. Unfortunately I have little trouble to recognize which is the original of v1.2.24-25. I assume that I am using the source code of Mike Gaitens, who added some extras to Xeffort and who obviously understood a lot of that stuff (see http://www.xeffort.com/xeffort/xeffort_download.htm; unfortunately I have to report the sad news that Mike passed away some time ago).
Hope this helps you a bit.

[Neels]

From memory when I was trying to debug it, Jugoslav wrote an extra byte which he then wrote over with this line. I do not fully follow what is being done though. I will look through your version Joerg.

Bad news about Mike.

[Neels]

I get the following two errors when compiling software that uses Joerg's version:

 error LNK2019: unresolved external symbol _XMESSAGEFONTHNDL referenced in function _XFTDIALOG_mp_XMESSAGEBOX      

error LNK2019: unresolved external symbol _XGETMESSAGEFONT referenced in function _XFTDIALOG_mp_XMESSAGEBOX            

[joerg_kuthe]

Sorry about this. I have uploaded a XMessageFontHndl. Hope this helps.