With the latest compiler updates on the latest Windows 10 machines I get the following:
Are there other users of Xeffort that can help or maybe Steve can have a look?
I tried a couple of the sample Xeffort projects (tbtest and xgraph) and, once I adjusted for the compiler now checking consistency of INTENT for passed-procedure dummy arguments, both worked fine. I used the latest Xeffort_IVF11_1225.exe installer and didn't rebuild any of Xeffort. I am using compiler 19.0.1 on Windows 10 1809.
Can you put together a small example project that demonstrates the problem?
My problem with the Win10 issue I cannot reproduce. Of a user base of more than 400 worldwide I have 3 users reporting the issue. They all have new computers with the latest Win10 loaded.
When I try to compile Xeffort I get error messages. Can you please try to compile it and suggest how to fix the errors? I use the latest compiler.
The problems begin in module XFTStrings, which has the following:
RECURSIVE FUNCTION XLoadString(ID, hModule) RESULT(s) INTEGER, INTENT(IN):: ID INTEGER, OPTIONAL, INTENT(IN):: hModule CHARACTER(LEN=PXLoadStringLen(ID, hModule)):: s ...
The compiler complains:
error #6582: A dummy argument which has the OPTIONAL or the INTENT(OUT) attribute is not allowed in this specification expression. [HMODULE]
which it is correct in doing so. It will take me a while to sort this out - and see what else is lurking. In the meantime I recommend simply using the prebuilt libraries and modules from the installer.
FWIW, I received an email a few weeks ago from a commercial software vendor, indicating that they had an effort (!) underway to update Xeffort and make it available for X64 (currently there is no 64-bit build.) I have not been in further contact with them so I don't know exactly what their plans are, nor how far they have proceeded.
I never claimed the source I supplied would solve your dialog issue, only that it allows Xeffort to build using a current compiler. Since you can now build it, you should be able to debug your application and follow what happens when you try to display that dialog.
Where does the text for the message box come from? Is it a resource string or coded into your application? I ask because one of the routines I changed dealt directly with loading a resource string. If you can provide a test case I can take a look, but you have all the resources I would have.
Ok, I've started looking at this but it's complicated, and I have other things going on. I can't make any promises.
I do not know enough but the following is first the Xeffort interface and then the user32.f90 interface to the same DialogBoxIndirectParamA:
!Xeffort INTERFACE INTEGER FUNCTION DialogBoxIndirectParam(hInstance, hDialogTemplate, hWndParent, & lpDialogFunc, dwInitParam) !DEC$ ATTRIBUTES STDCALL, ALIAS: '_DialogBoxIndirectParamA@20' :: DialogBoxIndirectParam integer hInstance integer hDialogTemplate integer hWndParent integer lpDialogFunc integer dwInitParam END FUNCTION END INTERFACE !!user32 INTERFACE FUNCTION DialogBoxIndirectParam( & hInstance, & hDialogTemplate, & hWndParent, & lpDialogFunc, & dwInitParam) use ifwinty integer(INT_PTR) :: DialogBoxIndirectParam ! INT_PTR !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'DialogBoxIndirectParamA' :: DialogBoxIndirectParam integer(HANDLE) hInstance ! HINSTANCE hInstance !DEC$ ATTRIBUTES REFERENCE, ALLOW_NULL :: hDialogTemplate TYPE(T_DLGTEMPLATE) hDialogTemplate ! LPCDLGTEMPLATEA hDialogTemplate integer(HANDLE) hWndParent ! HWND hWndParent integer(LPVOID) lpDialogFunc ! DLGPROC lpDialogFunc integer(LONG_PTR) dwInitParam ! LPARAM dwInitParam END FUNCTION END INTERFACE
Is this maybe part of the issue?
I was looking at that, but so far don't see a problem given the way the call is coded. (A reminder to those following along, Xeffort is currently 32-bit only.) It's the dwInitParam argument that could be questionable, but this is just an arbitrary value passed and I think it's ok. The part I am looking at is where it renders the passed in text in a font that it has loaded. Something is not working right there, but I don't yet know what.
You do not think Jugoslav has maybe used a scale factor that now makes it very very small or shifts it off the display area or something to that effect?
No. What I suspect is that there's a subtle error in Jugoslav's code that leads to something uninitialized. But I need to step through the code carefully. I might have to try building Xeffort with the 11.1 compiler to see what it does, but I'd rather not have to go that far.
Steve, I have an old laptop with 11.1 compiler and Visual Studio 2005 on it. (And Windows Vista :( ) If you want to instrument some Xeffort files with write statements etc I can compile and run them and send you the results.
If you can do a debug build of Xeffort with 11.1 (note that it puts the build in a different location), zip it and attach it here, that would help.