ver 0.3.0 FILE SAVE problem

[Turgut Guneysu]

Hi John,

Noticed another anomaly today while saving files.

I have a program named BattleShip5 in D:\PGMDev&Tech__microBlocks\uBlocks_PROJECTS - SYNCH\BattleShip5.

When I open the File/Save dialog, the File name field is correctly populated with the above path & filename.

At this point, if Okay is selected, even though the directory positioning is NOT at the correct place in Windows, since the file path is correct it should save correctly to the shown path. However it does not, because it is adding an additional “C-Drive User path” in front of the shown path, thus creating a mis-formed path:

Corresponding Command.com window display:

Could not open file for writing: C:\Users\Turgut/Documents/MicroBlocks/D:\PGMDev&Tech__microBlocks\uBlocks_PROJECTS - SYNCH\BattleShip5.ubp

RELATED But Different Problem:

Normally, this would not be encountered since the program positions correctly at the original File save and subsequent Opens. However, if one wants to change the location of the file to be saved, then this presents a problem.

As one proceeds through the File save menus, File name field starts out with the correct FULL path to the program file.

e.g.: D:\PGMDev&Tech__microBlocks\uBlocks_PROJECTS - SYNCH\BattleShip5

Then as one proceeds to select various Directories on the way to the final destination, the File name field does NOT maintain the path list, but rather just changes to the very last selection (directory or filename) from the menu. Here is a sequence of screenshots showing what I mean:

After clicking MicroBlocks on the LEFT - File name: BattleShip5

After clicking [ ] uBlocks_PROJECTS on the menu - File name: uBlocks_PROJECTS !!!

If at this point one selects OKAY and terminates the Save sequence, one ends up with a file on disk named uBlocks_PROJECTS.ubp . This should have never happened, as “uBlocks_PROJECTS” is a DIRECTORY Name. But in the process of path traversals it gets to be the new file name !

‌

[Bernat Romagosa]

Hi Turgut,

Was this happening before 0.3.0? I’ve made some changes to file dialogs and I fear I may have broken something for Windows.

I’ll take a look on Friday, I’m totally booked until then… sorry about that!

[Turgut Guneysu]

Hello Bernat

I will reload the previous version and test and report. No worries about rushing to fix. It is only an issue when the save location is changed.

Thx, TG

‌

‌

[Turgut Guneysu]

HI Bernat,

Verified the issue using the previous release 0.2.8 and it does NOT happen there.

The File name field stays set to the current program name throughout the entire directory traversals and

when save is completed, it writes the correct file name to the selected directory.

So, it something that changed in the ver 0.3.0.

[Bernat Romagosa]

partially fixes #61: only set filename field to selection if selection is a file

→ <<cset 0923f97d56eb>>

[Bernat Romagosa]

Hi Turgut.

I’ve fixed the issue with file selection. Let’s see if that also fixes the first issue when we release 0.3.1

[John Maloney]

Merge branch 'master' of https://bitbucket.org/john_maloney/smallvm

• 'master' of https://bitbucket.org/john_maloney/smallvm: Create temp directory in case it doesn't exist. Was an issue in many schools using Windows Windows uses backslash for paths added (hidden) send and receive packet prims to Radio library more changes by Jose Garcia: servo and pwm pin mapping fix for ED1 Jose Garcia's changes to support servos and analogWrite on ESP32 boards Included Victor Casado's fix to AP mode. Now confirmed to work with NodeMCUs partially fixes #61: only set filename field to selection if selection is a file button events library sends the _buttonLoop broadcast only once added new Worm game added Turgut's Helicopter game fixed WoT library event description generation

→ <<cset b24cdd8e8d59>>