Silverfrost Forums

Welcome to our forums

Creating a new folder

15 Jun 2014 9:16 #14205

Is there a standard dialog to create a new folder? I know there is subroutine MKDIR@ but this needs a path to be already defined - it doesn't provide the dialog window to speicfy this path. To select an existing directory there is BROWSE_FOR_FOLDER@ but this doesn't seem to allow creation of a new folder.

15 Jun 2014 9:40 #14206

I do not know of a standard dialog box that only creates a new folder but the standard Open and Save As dialog boxes also allow you to create new folders.

15 Jun 2014 10:26 #14207

Many thanks for the quick reply, Paul! Yes, I know that this can be done, but it's not really a neat solution, as the prime function of these dialogs is to define file paths - it needs a right-click to select the new folder option. Not altogether sure how this path would be returned without selection of a file, which I don't want to have to do: at this point in the program it's just creation of a folder in which to save a number of new files.

  • Steve
16 Jun 2014 6:06 #14209

In theory you could write your own dialog using ClearWin+ with %bv and possibly %lv but it would not be easy.

16 Jun 2014 7:10 #14210

Yes, that was my thought too. I think for the present I'll set up a simple text box for the user to type in the required path to the new directory, which can then be passed to MKDIR@. Primitive but workable! Can replace it later by something a bit cleverer.

16 Jun 2014 7:45 #14214

Quoted from silicondale Primitive but workable! Can replace it later by something a bit cleverer.

Hi Steve,

How about something simple like this sample.

Actually the browse for folder dialog can create folders. The easiest approach to accomplish that is to use COM-automation on the Shell.Application COM-object. The sample project I linked above includes a small DLL for that purpose.

Have fun!

17 Jun 2014 5:51 #14215

Thanks for this Jalih. I now see that SHBrowseForFolder can be used create new folders. This function is called within browse_for_folder@ so presumably I could add this functionality to ClearWin+.

I will add this to the wish list.

17 Jun 2014 7:02 #14217

Many thanks, jalih - for the 'something cleverer' ! Will try it today.

[edit] Just tried it - simply brilliant! It does exactly what I needed. Many thanks for this.

11 Aug 2014 11:54 #14442

Hi, Jalih -- although that works brilliantly on my computer, a friend who is testing it has trouble installing. He uses BitDefender security, and it reports a trojan and refuses to load browse.dll (Gen:Trojan.Heur.GM.0144010002). I have to say that I've tried with Norton, Sophos, and Microsoft antivirus and none of these detect any problem. Could be a false positive from BitDefender but I thought I should tell you!

Just did a Metascan and 4 out of 40 antivirus programs detected this trojan - apart from Bitdefender these were F-Secure, Emsisoft, and Lavasoft. The other 36 said it was clean.

15 Aug 2014 3:10 #14448

Quoted from silicondale ...a friend who is testing it has trouble installing. He uses BitDefender security, and it reports a trojan and refuses to load browse.dll (Gen:Trojan.Heur.GM.0144010002). I have to say that I've tried with Norton, Sophos, and Microsoft antivirus and none of these detect any problem. Could be a false positive from BitDefender but I thought I should tell you!

Sorry for the late reply. Anyway, browse.dll should be clean. I use Microsoft antivirus and Avast myself. Avast in particulary has a tendency to report a lot of files as malware. It even deleted most of the files during adw modula-2 compiler installation.

Below is the minibasic source code for the browse.dll:

##NOCONSOLE
##MAKEDLL

export BrowseForFolder
func BrowseForFolder(string title, string buffer)
	IUnknown *objShell
	IDispatch *objFolder, *objFolderItem
	string *path

	objShell = CreateComObject('Shell.Application', '')
	if objShell = NULL
		buffer = ''
		return
	endif

	GetComProperty(objShell, '%o', &objFolder, '.BrowseForFolder(%d,%s, %d)', 0, title, 0)
	if objFolder = NULL
		buffer = ''
	else
		GetComProperty(objFolder, '%o', &objFolderItem, '.Self')
		GetComProperty(objFolderItem, '%s', &path, '.Path')
		buffer = #path
		SysFreeString(path)
		objFolderItem->Release()
		objFolder->Release()
	endif
	objShell->Release()
endf
15 Aug 2014 4:32 #14449

many thanks, jalih - I thought as much! I had a similar problem today loading a java update, which was rejected by Norton. Some of the antivirus programs are getting a bit too fierce.

23 Aug 2014 6:56 #14488

Hi Steve, it's time to update into this decade...

Could you test this project?

I made a quick attempt to use Windows 7 style file dialogs.

24 Aug 2014 1:59 #14497

Hi, jalih .. getting virus warnings again. Virus.Win32.Heur.l on the browse.exe file, and Norton has just deleted the dll files for containing 'Suspicious.Cloud.7.EP'

However, I did buy the Minibasic compiler and rebuilt the one you sent before, whcih scans clean. Could do the same with this one.

10 Feb 2015 11:23 #15625

It turns out that there is an existing undocumented function for this.

Here is a sample program.

program main
include <windows.ins>
logical L
character(256) path
L = browse_for_folder1@(0,'Some instructions',path,Z'40')
if(L) print*, path
end

Notes:

  1. The first argument can be set to the HWND of the parent window.
  2. Google search for 'BROWSEINFO structure MSDN' for flags other than Z'40'.
29 Dec 2016 6:26 #18631

This sample code now gives ne a floating point stack fault. I ran this example after my code failed.

It is interesting to note that whether or not the Z'40' or z'41' is present, the dialog always allows making a new folder.

29 Dec 2016 6:41 #18632

Oops. Forgot to include the error.

Floating point stack fault
Floating point stack fault at address 74d9677f

 74d9677f routine at address 74D9677F [+0000]

 74d97048 routine at address 74D97048 [+0000]

 74d96f02 routine at address 74D96F02 [+0000]

 74d969eb routine at address 74D969EB [+0000]

 74d9765a routine at address 74D9765A [+0000]

 74da3874 routine at address 74DA3874 [+0000]

 74da3650 routine at address 74DA3650 [+0000]

 74da3c25 routine at address 74DA3C25 [+0000]


eax=e0eec63f   ebx=0360ca70   ecx=e3af7faa
edx=41328a60   esi=00000000   edi=00000000
ebp=0360c9cc   esp=0360c938   IOPL=0
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00210286 [NC EP NZ NS DN NV]

 74d9677f  fcomp    [ebx+0x60] 
 74d96782  fstsw         ax 
 74d96784  testb    ah,0x41 

Program was compiled under CHECKMATE WIN32, all default options.

30 Dec 2016 4:30 #18633

The plot thickens.

Yesterday, I installed some SW that also installed some Microsoft DLL's (I think). Microsoft Visual C++2015 redistributables (x64 and x86) 14.0.24210

This BROWSE software that failed on that one machine runs quite nicely on a different machine that does not have this new software.

I'll try to narrow down what was installed.

30 Dec 2016 8:16 #18634

For me browse_for_folder@ and browse_for_folder1@ both work OK for 32 bit applications but both fail for 64 bit applications. They may never have been tested for 64 bits.

30 Dec 2016 3:15 #18637

Only using the 32-bit here.

I just removed the 2015 redistributables, and rebooted the machine, but the problem still exists.

Any suggestions as to where to look to determine why the same code (compiled separately, but using the same MAKE files) on the two machines works differently would be appreciated.

Thanks, Bill

30 Dec 2016 5:15 #18638

OK, definitely my user account on this single machine. But no clue as to why. Logged into a user account on this machine, all runs fine. Runs fine on another machine that has no development SW on it, that worked well.

Have run a System Scan to see if any files are damaged. Nothing showed as needing fixing.

Might I have some FTN95 DLL that is out of date that is being used just in my user (and non-privileged) account?

Please login to reply.