Files not being deleted

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
I'm saving out some .png files and need to delete temporary files on closing the app. I have an OnClose method as follows (also called when quitting via escape key) but it doesn't delete the temporary files even though they exist and are greater than zero bytes. Does DeleteFile() maybe require a full path and if so what's the most reliable way of setting it?

Also, should OnClose() be changed so as not to require a return value? Since it needs to call EndApp() any return statement is unreachable. I suppose you could call OnClose() and when it returns (I assume it returns, I haven't tried it!) call EndApp() but that seems kind of weird and defeats the object of having an OnClose event.

This is GLFW/debug build on Linux:

Cerberus X:
    Method OnClose:Int()
        ' cleanup temporary files
        If FileSize("tile1.png") = 0 Then DeleteFile("tile1.png")
        If FileSize("tile2.png") = 0 Then DeleteFile("tile2.png")
        If FileSize("tile3.png") = 0 Then DeleteFile("tile3.png")
        EndApp()
        ' unreachable!
        Return 0
    End
delete-files.png
 

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
Two things.

I doubt Filesize = 0 is what you want. Rather <>0.
And there is no need to call EndApp in OnClose as the app is closing anyway at this point.
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
I doubt Filesize = 0 is what you want. Rather <>0.
Sorry just mis-typed that here.

With regard to EndApp(), what you say is what I'd expect to happen but OnClose() by itself doesn't exit the app.

EDIT: And help seems to imply that you need to add EndApp() to OnClose() if extending App:
"By default, the OnClose method calls EndApp. To override this behavior, you must provide your own OnClose method when extending the App class."

EDIT2: I've got an idea why the files aren't being deleted... I suspect I've been looking at the /release folder that I was testing rather than /debug LOL. :oops:
 
Last edited:

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
You are correct about EndApp. I was wrong.
So maybe remove the return value from OnClose()?

EDIT: And I've just checked and files are being properly deleted, so I was wrong too :D
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
Naah, down want to break compability and also ALL On... methods have this return value.
Well I don't know what it might break but it seems a bit odd requiring a return value that you can't return!
 

Phil7

Moderator
Joined
Jun 26, 2017
What about implementing a Close() Method wich calls OnClose()?
I think the only downside is that you have to change all calls of OnClose() to Close() in Cerberus (Didn't do a source search ).
It wouldn't break old code AFAIK and would give you the possibillity to end your app properly from inside your code.

Cerberus X:
Method Close:Int()
    OnClose()
    EndApp
End

Method OnClose:Int()
End
 
Last edited:

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
No, your example would break the ability, not to close the app. Like asking for confirmation to close. Not possible with your example.
I think OnClose works fine as it is.

And whata change could break? Any code that has implemented it in Strict mode.
 

Phil7

Moderator
Joined
Jun 26, 2017
And whata change could break? Any code that has implemented it in Strict mode.
I don't understand what you are saying here? :oops:

I was thinking of changing these Methods in mojo.app.

ability, not to close the app. Like asking for confirmation to close. Not possible with your example.
You are right.
This would be a nice way to have a useful return value:
Cerberus X:
Method Close:Int()
    If OnClose() = 0
        EndApp
    Endif
End

Method OnClose:Int()
End
I think OnClose works fine as it is.
True. Just thinking about a convenient solution for @Paul59 s problem of useless return values.
 

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
I don't understand what you are saying here?
The definition currently is with Int as return values.
So if someones codes with Strict turned on, they have to define their return values the same.
Now if you exchange the Int to Void, any former Strict implementation of these methods in user code will break and Trans will greet you with

1573070498112.png


Sure such things can be changed and it would make sense to change in the official implementation. But I am oppose to that in the current version, for the reasons above. Because if you think this further, were do you stop? Remove the return values, change the names of properties in classes, prefix classnames with a c, etc. etc.
All makes sense, but that should be done in a so called version 2.
 

Phil7

Moderator
Joined
Jun 26, 2017
etc. etc.
All makes sense, but that should be done in a so called version 2.
That's true for sure!

It might be a good idea to collect those thoughts somehow. And to me it is allways better to have a quick tinker session about possible solutions, rather than stopping at having a problem. At least when I am in building/coding mode, I often lose the perspective of a user.
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
Is it possible to chain a call to EndApp() automatically after executing OnClose()? That way OnClose() could be for clean up code only, still return an int as per all the other callback methods but then automatically call EndApp(). Or the program could call EndApp() directly if no clean up is required.
 

Holzchopf

Moderator
Joined
Jul 31, 2017
Location
Bern, Switzerland
I don't see the necessity in that. On the GLFW target, OnClose() is called when you hit the X in the top right. And there are cases where you don't want the app to actually stop running as reaction to that. IMHO the programmer has to have the freedom to decide how an app should react and therefore, automatically executing EndApp() can't be the way to go.
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
And there are cases where you don't want the app to actually stop running as reaction to that.
I hadn't considered that, I suppose if you're writing some other sort of non-interactive program using CX then that might apply. I'll just use OnClose() for clean-up code if needed then execute EndApp() after it returns. Seems a bit odd but as you say it keeps things flexible.
 
Top Bottom