Bit curious here. This program is one of Bill's, which removes .a, .o and .aout files from your IWB directories. I've just tarted it up a bit, that's all. Not changed any of the clever stuff
I can compile and run it fine here (Win 10 Pro, 64-bit), but when Bill runs it, and selects Browse to choose his source folder, it falls over and closes down. I just don't have that problem
Anyone care to either run the exe, or compile it themselves and run it, and see what the outcome is? And if you spot anything, all the better!
Brian
Since you already have tried with Win 10 Pro/64-bit, I compiled and tried it on my old pc running Win 7 Pro/64-bit. Works like a dream!
But I once had a similar problem when trying to run a program compiled on 64-bit win7 Pro on 32-bits XP. I did not try to solve the problem at that time, since I already had ordered Win 7 to upgrade my old XP-setup.
Egil
Just a reminder; there's a File CleanUp utility under the Tools menu in the IWB3.x IDE that will do all that for you and you can add whatever file extension you want to it.
Well, I didn't know that, probably because I don't use the new IDE so much. I reckoned that posting SOME code was better than seeing the forum lying dormant most days
Brian
Quote from: Brian on March 29, 2019, 04:10:58 PMI reckoned that posting SOME code was better than seeing the forum lying dormant most days
Brian
You're right about that.
The code is using the SHBrowseForFolder function. You must initialize Component Object Model (COM) before use it.
Call CoInitialize(0) when the program start and CoUninitialize() when the program ends. If you require drag-and-drop functionality, you need to call OleInitialize(0) / OleUninitialize() instead.
As a general rule almost any api function that starts with SH*** will need COM, Otherwise, it will crash on some systems. I don't know where exactly.
Gabriel,
Thanks for that - I will plug that code in. But I still don't understand why the same code crashes for Bill and not for me
Brian
Tried the CoInitialize(0) and CoUninitialize() and it still aborts.
Bill
Strange. And removing the callback?
bi.lpfn= 0 ' &BrowseFolderCallback
Tried removing the callback, still aborts.
Bill
Ok. here are some additional things that could be done
- Try commenting this line also
'bi.lParam=initial
- Check if it is exactly at the below line where the crash is taking place.
item_list=SHBrowseForFolder(&bi)
- If so, delete BROWSEINFO, SHGetPathFromIDList and SHBrowseForFolder declarations, and include Shlobj
$include "Shlobj.inc"
... and replace this line
bi.hwndOwner=hWnd
If nothing of this works, I'm afraid I'm out of ideas. :-[
Tried every one of your suggestions and still aborts.
However added 1 line of code between the following and it worked. See line in blue:
CloseHandle(hFile)
dir = GETSTARTPATH
DIALOG d1
Now it does not abort.
Weird....
Thanks,
Bill
Strange - I have also noticed issues with getstartpath between Win 7 and Win 10.
I have re-written the way it works in the new compiler.
Not sure if it was really at fault but I re-did it it anyway.
Larry
That dir variable seems to go to
bi.lParam=initial
so it was there the problem after all, but not in the way I was thinking. Nice catch by the way. Glad you solved the issue.
Larry. I find discrepancies between Win10 and Win7 all the time. Maybe because Win10 itself is using .NET in their system apps now. But who knows for sure?
Well, between us we got there! Here's the updated code, with contributions from Bill and Fasecero
Brian