Simple write text file to desktop

Getting Started
1

I have always struggled to try and understand how Xojo works with simple files and have looked at the examples and just get more confused.

I am trying to do something really simple but need help. All I want to do is write a text file to the desktop called “mytextfile.txt” with the text content of “Hello World!”. I dont want a dialog or anything else, just simply write a text file.

Thanks

2

with absolutely no error checking

// get a reference to the folderitem (which may or may not exist)
dim f as folderitem = specialFolder.Desktop.Child("mytextfile.txt") 

// try and create the file at the location the folderitem refers to
dim tos as TextOutputStream = TextOutputStream.Create(f) 

// write my text into the new text output stream
tos.write "Hello World!" 

// and nil things so they get flushed etc
tos = nil 
f = nil
3

The documentation for TextOutputStream has the most basic of examples for writing files. It doesn’t get any more basic :confused:
http://documentation.xojo.com/index.php/TextOutputStream

Be aware that not presenting the user with an Open or Save dialog will cause you a lot of headaches on Mac down the road. If this is only a learning exercise you’ll be fine.

Edit: Beat by 10 seconds :stuck_out_tongue:

4

But I thought that the GetSaveFolderItem shows the save dialog box

[quote=361444:@Norman Palardy]dim f as folderitem = specialFolder.Desktop.Child(“mytextfile.txt”)
dim tos as TextOutputStream = TextOutputStream.Create(f)
tos.write “Hello World!”
tos = nil
f = nil[/quote]

Thanks Norman that is exactly what I was after. It was the .Child bit I didnt realise you could do.

5

[quote=361444:@Norman Palardy]with absolutely no error checking

[/quote]

Is there any reason you don’t issue a close on the stream? Will the nil bit not leave a file handle open in the OS?

6

I would think that

tos.close

would be the proper way to close the file, and insure that the memory buffer is written

7

closing the stream leaves you with a non-nil reference that you literally cannot use for anything after the point you close it
but it’s also not nil

niling it means that the destructor runs which will force it to be flushed
AND if you try to use it for anything after this point you’re going to get a nil object exception

that wont happen if you just close it

8

Thanks. I get the nil implications - I have always been in the habit of issuing a close first.

9

Here’s the specific problem
<https://xojo.com/issue/40132>

10

[quote=361487:@Norman Palardy]closing the stream leaves you with a non-nil reference that you literally cannot use for anything after the point you close it
but it’s also not nil

niling it means that the destructor runs which will force it to be flushed
AND if you try to use it for anything after this point you’re going to get a nil object exception

that wont happen if you just close it[/quote]
sounds like a deficit in the CLOSE command then (my opinion)
especially since Xojo own documentation makes more use of CLOSE than NIL in this regard

CLOSE indicates the intent… Nil doesn’t

11

All CLOSE could ever do is close the stream and then make it so any further operations throw an exception/error

Niling it does exactly that already

12

LOL… so the result is the same… while CLOSE makes the intent perfectly clear…
Thank you for making my point … again…

13

It does.
Use that when you want to give the user a choice.

If not, then you use GetFolderItem () to construct a file from one or more bits of ‘path’
or a child of SpecialFolder, as the example above.

14

Except one big difference
NIL works - today
Close doesn’t

15

[quote=361559:@Norman Palardy]Except one big difference
NIL works - today
Close doesn’t[/quote]
mind explaining that?
CLOSE has been part of TextOutputStream since FOREVER… and works perfectly fine in the thousands of times I’ve used it.
Xojo OWN documentation examples use CLOSE more than NIL

16

I think Norm’s point is that , for ‘safety’, using NIL ensures that …
If you later try to use the stream you will get a nilobjectexception

As opposed to

Which I would expect to generate some other kind of exception, personally.
As would anyone who tries to use a stream after the .close command is issued.
And of course if defined inside a method , it should nil when the method ends.

I hear what you say but I would never have expected/trusted that to happen just by setting a variable to nil.
I’ve been here before.
Objectively, I would not have been surprised by a bug report about ‘setting to nil without closing first causing mysterious memory leaks or locked files’.

I use .close()
… it does what it says on the tin, rather than hoping that the destructor will do it for you.
Set it to nil afterwards, if it satisfies a need.

17

[quote=361568:@Jeff Tullin]I
Objectively, I would not have been surprised by a bug report about ‘setting to nil without closing first causing mysterious memory leaks or locked files’.[/quote]
It doesn’t - that WOULD be a huge bug
Close followed by nil would be pedantic
Just niling it IS sufficient