i noticed something concerning two known bugs:
i just had a patch which couldn’t be saved.
-> a long known, occassionally bug.
i noticed that this patch stayed “onTop” without making use of “ctrl-T”.
-> the second occassionally bug.
after applying and disapplying “ctrl-T” it was possible to save the patch!
well, i am not sure at all if there is a coherence because that “notSaving”-bug exists way longer than that “ctrl-T”-Feature…
That naughty saving bug seems to have many different faces - and therefore many reasons.
I just ran into it again.
What I tried:
Nothing of this worked. But what did it for me, was:
Selecting all nodes of the patch and deleting them.
Then saving the patch. Pressing Ctrl-Z to undo the deletion.
Now I could save it!
Maybe this helps someone encountering the problem.
Just wanted to add:
The nasty thing about that bug is, that you don’t notice the save doesn’t work. I press ctrl+s all the time, but I don’t check if the * symbol disappears from the title bar. This way users lose hours of work easily!
Maybe you could throw an error message at the user, when saving didn’t work out. This would greatly diminish the impact of the bug.
Selecting all nodes of the patch and deleting them.
Then saving the patch. Pressing Ctrl-Z to undo the deletion.
Now I could save it!
wow. what a method. respect.
nice advice !!!
I just have one i can’t save:
02:06:22 ERR : Error caught in the act: TMMenuItemFrame : Zugriffsverletzung bei Adresse 005F1C56 in Modul ‘vvvv.exe’. Lesen von Adresse 00000038
today that method with deleting all nodes, saving, ctrl-z did NOT work.
vvvv.ck
2 days 19:03:11 ERR : Error caught in the act: TMMenuItemFrame : Zugriffsverletzung bei Adresse 00404848 in Modul ‘vvvv.exe’. Lesen von Adresse FFFFFFDC
2 days 19:04:02 ERR : Ungültige Zeigeroperation while Deleting Node of Type Add (String)
2 days 19:04:37 ERR : Error caught in the act: TApplication : Zugriffsverletzung bei Adresse 0051701E in Modul ‘vvvv.exe’. Lesen von Adresse 00000064
was previously messing with CreateEnum.
can somebody mark this thread as sticky?
i think this is the worst bug vvvv has and ever had.
here a list of related threads:
invisible patches
CANNOT save-bug.
StayOnTop
i assume that there are several independent bugs causing the same annoying symptom.
meanwhile i found several methods to “work around”.
the most important thing:
keep an eye on the * when saving
if you notice that problem: IMMEDIATELY check if that ~.xml file next to your patch is larger than 0kB.
if you already tried to save twice, you can be sure that this one is also 0kB now.if it is larger make a copy of this file.
puuh, now you have at least a little fallback.
can please somebody mark this thread as sticky?
hi devvvs:
next time i use capitals.
or even worse.
i found a reproduceable way to achieve the symptom:
my complete vvvv-folder of my laptop with exe, 100mB modules and projects is shared on LAN.
on almost every pc i work with i’m used start my ‘personal’ vvvv through LAN.
this works pretty fine and you don’t have to deal with wrong paths, missing modules etc.
yesterday i experienced this:
i had the same patch running on 2 PCs
i modified the patch on one pc and tried to save it.
Renderer TTY claimed sth like: couldn’t save backup-file
but vvvv was able to save a 0kB file.
Maybe if the can’t save bug is too hard to find, more than 1 incremental backup would help, maybe in a folder the patch resides in named backup which contains all the patches backups for that folder, then if it goes you can go back to where it still worked, and only loose a bit of work, instead of potentially all!
my findings and workaround:
it is usually only one node, that’s broken. i think it’s been only ioboxes, but not sure. the nodes that prevent the patch from being saved also deny being copied into the clipboard.
so to find out which one it is, select a bunch of nodes, and try to copy/paste it into another patch. if it works, the node in question has not been among the selected nodes. however, if the clipboard was not updated while copying- you hit the bugger.
that way it can be narrowed down until you find the node in question, which can then be replaced.
can’t say anything to the “stay on top” feature.
but save is now more robust.
when some erroronous behaviour during save is detected it won’t override your patch, nor the backup. it will just result in an additional patch:
somepatch~temp1.v4p
if you then gamble around and try to save again it will just result in more temp files.
hopefully more expressive errors (if something like that exists) are printed into the tty renderer.
if something failes during save the procedure will continue (knowing that only temp files should be created) and will still try to get the job done.
if everything looks fine for vvvv
yippie!!
this is a progress.
and a devvvv read the thread…
can please somebody mark this thread assticky?__
caught in the act with beta17
ai calle,
why would you want this thread sticky? to my understanding it doesn’t really offer a generally working solution to the admittedly severe problem. i’d rather wait for >beta19.1 and see what errormessages people get and see if that helps us fixing the thing completely. with the fixes for >beta19.1 the situation should already be greatly improved. bear with us…
hi IOrec,
i am veryverymany sure that the “Can’t Save”-thing is only a symptom for several bugs.
i am very thankful that >19.1 will offer a ‘workaround’ because for us users this is surely the ‘worst’ case of ‘bug’ at all in our beloved toolkit.
intention is to have fast access to this thread in case of emergency.
usually when this happens your motivation to do a wiki search isn’t that high because you mostly have other priorities.
it seems that this issue is history since beta20.
i didn’t take notice of this anymore although i’m currently working on pretty large and complex patches over several pcs.
a big hug, devvvvs!
good to hear. anybody else with a testimonial on this?