Browse_for_folder1@ is failing to create a user-named folder

Hi Bill - You are not the only one with a Browse_for_folder1@ problem. Just discovered it today. I have the identical problem, and not sure how long it has been there, because most of the time I don't actually create new folders within my software. Using Windows10 on a 64-bit laptop, but still using 32-bit Fortran95. When creating a new user-named folder, it crashes the program without any message, though the folder is created.

Steve, was your Windows 10 an upgrade from 7 or 8? I'm thinking there was some incompatibility from that, but I don't believe I'll ever really know.

The reason I say that is I did a nuke and pave of the 'C' drive and re-installed my software. The problem disappeared.I would still like a better solution, but I don't have the time to do that. No user of mine has ever complained, so I guess it was only my development system with the issue. The laptop was an upgrade from 8 to 10, but home version, and had fewer applications and drivers installed.

Ah well.

Thanks for sharing. Thought I might be the only one with this issue. Not happy there is someone else with it, but knowing I'm not alone!!

No, it was a Windows10 that came new, with the computer. I have another more recent computer which I'm going to try it on - exactly the same executable. Different make, different age. (This one is HP, a couple of years old, the other one is Dell, less than a year old).

I'll let you know what happens.

cheers -Steve

It worked fine on the Dell. So the problem seems to be machine-related. Both machines are 64-bit, and have latest set of Microsoft updates so I have no idea what the difference would be. The HP has AMD A8 processor, the Dell has Intel I7. But that shouldn't make any difference.

OK, I have a workaround, which seems to work on both computers without a problem. Not quite so pretty, but it seems robust. It uses the older function browse_for_folder@ in combination with mkdir@

      logi = browse_for_folder@('Path for new folder?',where)
      newfolder = ' '
      k = winio@ ('New folder name? %10rs&',newfolder)
      k = winio@ ('%^bt[OK]','EXIT')
      ltw = len_trim(where)
      ltn = len_trim(newfolder)
      fullpath = where(1:ltw) // '' // newfolder(1:ltn)
      lf = len_trim(fullpath)
      call mkdir@ (fullpath(1:lf),nerr1)

[/url]

A problem such as this might have three possible causes:

1. an issue with FTN95
2. an issue with Windows
3. a hardware problem

I think it is fair to say that if it does not occur on every computer, then we can rule out the problem being an issue with FTN95. As to whether it is an issue with Windows, then if it does not occur on every computer then it is clearly not a systematic fault. The acid test on a particular computer as to whether it is a problem with the Windows installation or a hardware problem is ‘does the issue resolve itself with a clean install?’ In Bill’s case, it did resolve, so that is an important pointer to this being a Windows issue on a particular computer.

Why such problems should arise is in my view the result of interrupted or otherwise failed updates of Windows itself or of other software, this cause being more probable than conflicts between otherwise functional applications.

The clean install can be a problem for some users, and to do it requires having the appropriate facilities (including knowledge and courage) and time. Matters are simplified with Windows 10 because one does not need the initial installation material, as this can be downloaded from the Microsoft website to be put on a USB drive (if the computer in question will boot from USB), or put onto optical media. The whole process is made a lot easier if you manage your computer in a certain way. This way is to only have the operating system and applications on a particular drive, and all the data (which includes the source code for Fortran programs) on another. You can find a list of software that will need to be updated by printing a screenshot of the ‘Program files’ and ‘Program files (x86)’ folders.

I have built my own computers since the days of the 486, and have installed various versions of Windows and reinstalled them on many, many, occasions. In the beginning I followed the norm for commercially assembled computers in having only one hard drive. This is a big mistake, because you have to backup everything before you can even think about a Windows reinstall. I’ve learnt from experience that it is a good idea to have the minimum content on the boot drive. I’ve also learnt that one does not need a very big drive for this, as it removes some of the temptation to revert and keep too much information on the boot drive. I have also found that it is so much easier if the reinstall goes on to completely fresh drive. After all, they are cheap enough. One can take the opportunity of delving into the computer case to do other upgrades at the same time, including on occasions building a completely new computer.

Recently, I have found that price of SSDs has fallen remarkably. 120Gb is actually adequate, and the price for that can be less than GBP20. A larger 240Gb is more than is strictly necessary in most cases, and 480Gb is complete overkill. If you replace a mechanical HDD with an SSD, then it is rather like having a new computer anyway, because the most tedious wait which is when Windows restarts is dramatically shortened.

It is a grave mistake to clone the boot (OS) disk is that merely copies the software errors onto the new drive.

I mentioned above that one needs courage, and this is particularly so if you usually buy completely configured computers and have no experience of delving inside. Such computers normally don’t come with installation media, and Windows 10 resolves this problem. Win 10 does, however, increase the risk of some update issues because updates are done in the background and you have no idea what is being done and whether it has completed before you switch the machine off.

While you are doing a clean reinstall of Windows, it is also a good time to take data discs out and clone them as a form of a backup. So-called ‘Quickport docks’ are very cheap, and the cloning function is done without the dock being connected to a PC. It therefore does not absorb any computer power while even a very large, multi-terabyte, disk is cloned. (Continued ...)

(Continued) My own particular history has left me with rather a lot of hard drives that I have simply replaced. Had I been smarter, and indeed had I had a quickport dock in the past, then I might have been able to reuse them. I rather dislike waste, as in the past I have assembled discarded parts to give away or sell on. A lot of hard disks makes one think immediately of backup. There are numerous lines of approach to backing up that have nothing to do with this thread and so I will put them in another post in the ‘General’ part of the forum.

But, for the issue initially described by Bill, the answer is simply a clean install of Windows. An FTN95 workaround is a great idea, but once windows has any kind of glitch, you are simply waiting for worse to happen in the future.

Eddie

Many thanks for the detailed explanations, Eddie, and the benefit of your experience. I think you have correctly identified the problem as something in Windows - and in particular, glitches that might have been introduced by failed updates: on this computer (the one which had the problem) a Windows update certainly did fail a few weeks ago. Although subsequent updates worked fine, it's possible that they didn't fix the glitch.

Courage is another matter. This is an off-the-shelf HP Pavilion laptop, and I doubt that I would find space in it to fit another disk or even SSD, and would have no confidence in getting the cabling right. I could partition the existing hard disk, but would need to reorganise the storage. The other computer is a top-of-range Dell which already has a separate SSD C:/drive, but as it works fine I wouldn't need to do anything to it anyway.

The big problem is when I am supplying my software to other team members to use. I just create a standard installation script for them to use. I have no idea in advance what machine they are going to install it on, and am very reluctant to tell them they have to reinstall Windows it it doesn't work properly! Before I set up the MKDIR@ fix in my last post, I told them the workaround was to create any new folders they need in advance, using Windows Explorer. The fix at least avoids that inconvenience, and it seems to avoid whatever Windows problem is giving trouble.

Perhaps another solution less drastic than a clean install might be to run the next cumulative update from Microsoft. Not sure if it's possible to make this go back and fix any problems in previously installed updates. Do you know the answer to this?

Wow, that was quick!

Laptops are a big issue, as they don't normally have space for spare disks, and the solution there is to partition the single hard drive so that you have a boot partition and a data partition. This is functionally the same as separate disks. I was making the assumption that desktop machines were being considered. I rarely have the back off a laptop! If you have someone who is unafraid, the same procedures can be done: take out the hdd, install a new one, reinstall Windows into a partitioned hdd/ssd, bung the old drive into a quickport dock and reload all the data, reinstall any necessary other software, and Robert is the sibling of one of your parents.

I don't think cumulative updates ever really solve some of the occasional problems, that a minority of users have, in the way that clean installs do. There is another approach that lies beyond my expertise, and that is editing the Registry to discover the root cause of the problem. That, I'm afraid, is well beyond my knowledge and ability, and also contains the necessary elements to make a complete screw-up possible.

Indeed, doing a clean install on a new storage device leaves you with the ability to go back if you screwed up!

For what it's worth, my biggest experience of the interrupted or failed update glitch was that it made my accounts program fail to go full screen. It would launch itself into the taskbar and refuse to come out. Solved by a clean re-install. That machine had a Win 7 to 10 upgrade originally.

y 'installation script' I assume you mean a batch file. Have you considered using a proper installer like Jordan Russell Software InnoSetup? (Apologies if that's what you mean). It has the benefit of putting everything in one file, and automating the process.

Eddie

Thanks Eddie - It's Innosetup that I am using. And very happy with it! It not only installs my own software but also a couple of public domain VRML viewers that allow 3D visualisation of models (of the geological rather than glamour variety, I hasten to add).

Update: This function no longer works on my main machine, but still works on the laptop. I compiled and ran on the laptop (no problems), run on the desktop, crash. Sometimes it will crash with no traceback.

Whatever was fixed last year after my nuke and pave is now broken again.

I will continue to use it for my users, but not being able to properly test all the program paths by being able to create a new folder using the system dialog is a limiter for me.

BTW, I get a Floating Point Stack Fault (like before), several lines of addresses show (no names even in checkmate) and offsets specified as (+0000) on every line.

I don't recall, is this 32 bits or 64 bits and does it make a difference?

If Bill is getting FPU stack faults, it would have to be 32-bit, would it not? The X87 is the one that provides a stack view of the ST0-ST7 registers.

I missed that. In which case it might help if ClearWin+ clears the FP stack before making the call.

I have now done this for the next release of salflibc.dll.

Than ks, I'll give it a shot when it comes out.

In all the other things, I've been remiss in this after you had put out a new release.

It still does not work on my main system.

I (today) tried to capture the FP Stack Fault by setting the handler immediately before the browse_for_folder1@() call. What i got was a continuous stack fault handler being invoked. I tried using the code/edoc and the instruction FCLEX in the handler to clear the fault. If I do not enable the handler, the function will execute, but FP Stack Fault after I try to add a folder. So a couple of questions.

Using code/edoc, what instruction (or combination) could be used to clear the fault before the browse_for_folder1() gets called?

What instructions can be used to clear the stack fault, then return a 0 indicating the fault was handled?

Also, how does one re-install the Old Handler? CORE4(OLD_HANDLER)?

Bill

browse_for_folder1@ in the latest DLLs resets the floating point stack via fclex, finit, and fround at the beginning of the the function. So it won't make any difference if you do this in your code.

My guess is that you won't be able to recover from a floating point stack fault. When you handle it and say 'continue', the fault will still be there.

At the moment the 32 bit browse_for_folder@ and browse_for_folder1@ do not respond to 'alt_open_save' where as for 64 bits only the alternative is employed.

Is it possible for you to extract and test your call browse_for_folder1@ using 64 bits? I am thinking that if your cut down fails for 32 bits and works for 64 bits then perhaps I might be able to make the alternative available for 32 bits.

Paul, I will give this a try. Transferring my existing code to 64-bits is not something I can do quickly. That said, I will see what I can do to get the problem to occur/not-occur between the two platforms and let you know.

Appreciate you taking another shot at this.

Bill

Paul, I used the little test program I originally posted, and ran it as a 64-bit. Here's what I see.

When I run it, I get a DOS box displayed (which is curious - is that supposed to happen). I navigate to where I want a folder and click 'Make a New Folder'. The folder name came up (in this case New Folder (2)). I change the name of the folder and click OK. Then things get strange.

Just briefly in the window, I see my changed name return to New Folder (2). The program returns the name New Folder (2) as my folder name. However, the folder name I typed is created. This works the same way with the UNIT specified as either Z'40' and Z'41'.

The same behavior in both Checkmate and Release 64.

	winapp
	PROGRAM MAIN
	use mswin
	character*260:: returned_path=' '
	integer:: uint=z'40'
	integer(7):: window_handle=0
	if(browse_for_folder1@(window_handle,'Caption',returned_path,uint)) then
	print *,'Returned:',trim(returned_path)
	else
	print *,'Cancelled'
	endif
	end

With the 32-bit attempt, a portion of the same behavior is seen. That is, after typing a new name and clicking OK, the New Folder (2) shows briefly, and the program crashes with no trace. The newly named folder does appear when looking at the folder in Explorer.