QtVCP file save

Attached is a patch that uses the same dialog for saving a file as is used for opening a file.
I have attempted to follow the same procedure as for opening files, hopefully I have not overlooked anything.
One thing I would like to add as I think this is a personal preference would be to have a setting somewhere (preferences???) that if set would also load the file into the machine control after a successful save.

Cheers, Phill.

That's great work Phill.
It's made me think more about the dialog requests message protocol.
I'm much preferring the newer 'dialog-request' using a DICT of commands, rather then separate file-requests, save requests and dialog requests.
I'm thinking making them all dialog requests with different DICT messages and removing the load and save GObject messages.

The nice thing about the DICT message is that in the future if we need to add capabilities it won't break older style code.

So I envision that the gcode-editor will request a save dialog to get the file name.
that will be returned to the gcode editor and the gcode editor will actual hold the code for saving (using your ACTION code) and that would be the place for adding the preference file option to reload after saving.

I'll work on your patch tomorrow.
It's great to have someone else adding code - Thank you!

Chris m

Thanks Chris, that sounds like a plan.

On my screen I removed the buttons for hal show etc. etc. with the intention of using the mdi_line but I kinda snookered myself because it seems the machine needs to be on and homed to enable mdi_line. So...
1. Would it be feasible to enable mdi_line when out of estop but only allow commands other than CALL_MDI.
2. mdi_line only accepts upper case for these commands. I think if someone went to the trouble of entering these in lower case they probably meant to enter the command.

Cheers, Phill.

1) my only thought against this - is that it will lead users to believe they can sent MDI commands before homing - It would give them an error I suppose so not a big deal.
Here is a question - do you think you need this capability often or just when debugging something? If it's just for debugging -and debugging is rare we could have that behavior with a 'debugging mode' switch.

2) The upper case idea cam from Pilot Path I think. My thought is it would be hard for someone to accidentally invoke a command (say in a gcode comment) if we used all caps. I am not against allowing lower case and see if it's actually a problem.

cmorley wrote: 1) my only thought against this - is that it will lead users to believe they can sent MDI commands before homing - It would give them an error I suppose so not a big deal.
Here is a question - do you think you need this capability often or just when debugging something? If it's just for debugging -and debugging is rare we could have that behavior with a 'debugging mode' switch.

Not often, it is just that personally I like "single page" screens so it is more with this in mind so I can save a bit of real estate.
[strike]Your idea of a "debuging mode" sounds good, maybe invoked by a setting in preferences.[/strike]
Doh! I just realised that I can do this from the handler file...

cmorley wrote: 2) The upper case idea cam from Pilot Path I think. My thought is it would be hard for someone to accidentally invoke a command (say in a gcode comment) if we used all caps. I am not against allowing lower case and see if it's actually a problem.

No worries, that was my lazy self thinking, I can handle using the shift key as well.

Cheers, Phill.

Ok we can revisit this if required later.

Chris