View previous topic :: View next topic |
Author |
Message |
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Wed May 24, 2023 9:56 pm Post subject: Is the get_filtered_file@ call usable? |
|
|
I'm trying to replace some C++ bridge code that opens a file dialog using an .exe and I'm calling the code below but it is crashing reliably.
This is in 64 bit.
If I add CALL CLEARWIN_OPTION@("alt_open_save") then I can get it working.
Is this still the recommended way to open a common dialog box natively from SilverFrost Fortran or am I missing something?
It seems very unreliable without the extra option which is not obvious.
Code: |
integer function select_file()
use mswin
integer :: res, number_of_filters
logical :: must_exist
character(len=128),dimension (10) :: filter_names, filters
character(len=128) :: file_name,path
character (len=20) :: title
title = 'select_file File';path = 'c:\';
file_name = 'fred.f95'
filter_names(1) = 'Text files';filters(1) = '*.txt';
filter_names(2) = 'Batch files'
filters(2) = '*.bat';
filter_names(3) = 'All files';filters(3) = '*.*'
number_of_filters = 3;must_exist = .true.
!CALL CLEARWIN_OPTION@("alt_open_save")
call get_filtered_file@(title, file_name, path,
& filter_names, filters, number_of_filters,must_exist)
res = winio@('%ca[Result]&')
res = winio@('%bg[BTNFACE]&')
res = winio@('You selected file "%ws"%2nl&', file_name)
res = winio@('%cn%bt[OK]')
select_file = 1
end function select_file
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8016 Location: Salford, UK
|
Posted: Thu May 25, 2023 7:13 am Post subject: |
|
|
Ryan
Yes you are on the right track but it is not usually necessary to use alt_open_save.
alt_open_save has the effect of loading the common dialog box in an external process and this in turn fixes an obscure Microsoft issue.
My impression is that the Microsoft issue relates to a lack of available memory. This would explain why it is intermittent since it then depends on the amount of physical memory available and the size of the folder structure that is being accessed. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Thu May 25, 2023 1:20 pm Post subject: |
|
|
Thanks Paul,
I'll do some more investigations but it is not behaving consistently between 32 and 64 bit. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Thu May 25, 2023 1:42 pm Post subject: |
|
|
It seems between 32 and 64 bit there is no single solution. I'll have to use #ifdef unless you have any suggestions.
Findings;
32 bit, no flag = Does not allow changing directory for ~30 seconds, then does a little bit and then stops again. Unstable.
32 bit, alt_open_save = Works, but does not remember previous dir.
32 bit, -alt_open_save = Does not allow changing directory for ~30 seconds, then does a little bit and then stops again. Unstable.
64 bit, no flag = Works fine and remembers dir.
64 bit, alt_open_save = Crashes with log noted as 1 below.
64 bit, -alt_open_save = Multiple 'Fatal error!' message boxes as log 2 below.
Log 1:
Silverfrost 64-bit exception report on C:\xxxx.exe Thu May 25 13:25:27 2023
Unknown exception (80010012) at address 7ff94535536c
Within file KERNELBASE.dll
In RaiseException at address 6C
In RpcRaiseException at address 50
Within file RPCRT4.dll
In RpcRaiseException at address 14
In HSTRING_UserUnmarshal64 at address 53C
Within file combase.dll
In NdrClientCall3 at address 99E
Within file RPCRT4.dll
In Ordinal147 at address 388C
Within file combase.dll
In ObjectStublessClient32 at address 7E62
In Ordinal87 at address 1A66
In DllGetClassObject at address 9D95
In DllGetClassObject at address C053
RAX = 00007ff945aafbd6 RBX = 0000000080010012 RCX = 0000000049be4fff RDX = 000000000000000f
RBP = 000000004997f408 RSI = 00007ff946881338 RDI = 0000000004af5501 RSP = 000000003d39eb60
R8 = 000000003d39ef40 R9 = 000000003d39e574 R10 = 00007ff945aafb62 R11 = 000000003d39ea00
R12 = 0000000000000000 R13 = 000000003d39edb0 R14 = 000000004997f408 R15 = 000000000000000e
7ff94535536c) db 0f,1f,44,00,00
Log 2:
"Exception @1a01b478: Access violation, Silverfrost exception handler has failed" and similarly but address @8819f1. Plus about 8 others. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 711 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Thu May 25, 2023 1:56 pm Post subject: |
|
|
This look very similar to the error Robert was asking about concerning select_printer@. While I could replicate that problem, it did not persist after the next windows update. Might be worthwhile checking that the windows installation is upto date. The referenced dlls are part of the operating system.
Your code runs OK on my machine. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Thu May 25, 2023 2:16 pm Post subject: |
|
|
I'm always up to date, so it's not that. It looks like memory corruption / buffer overruns to me.
Even the 64 bit version is not stable now.
I've figured out that the original developer had the out of process C++ window dialog for a reason. I think they hit all of these bugs over a decade ago. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8016 Location: Salford, UK
|
Posted: Thu May 25, 2023 4:25 pm Post subject: |
|
|
I think that the results may vary with the operating system and from one machine to another.
If you want a fix for "32 bit, alt_open_save = Works, but does not remember previous dir" then I could probably look into that. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Thu May 25, 2023 4:41 pm Post subject: |
|
|
I've found the 64 bit is unstable too so I'll look at patching the C++ app for now.
Thank you. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2865 Location: South Pole, Antarctica
|
Posted: Sat Jun 03, 2023 1:56 am Post subject: |
|
|
While i have typically many issues with my programs but notorious get_filtered_file@ or similar Open/Save/SaveAs/Close files in %eb work last 15 years without any problem at all. Now in Linux Mint+Wine they still work ok. Somehow my devilry punishment mixed me up with somebody else and decided to harass me with Linux where i already broke 3 Linux installations
May be the length of names and maximum number of files is important for get_filtered_file@ work properly?
I see that in one case which never failed at all i used 128 characters for the file names, and maximum 1600 files as a limit in the directory (who cares? Take any large numbers, memory is cheap now. Though i a bit forgot how all that works). Now i would try 256, 320 or even 512 for the length of filenames. |
|
Back to top |
|
|
|