Ah HAH! Now I get it! Thank you for repeating it enough to turn on the
, sorry for being so dense, but there are so many things I still don't understand about how things work in this language
See, since every version of the IDE I work with had 'Save As..." with older versions, I just assumed they all were using "with format (x)" to do the save, and didn't realize they must be using "stackFileVersion" instead (there is still a lot of code I haven't gotten too in the IDE).
NOW I get it. Boy do I feel like such a shmoe
mwieder wrote: Tue Jul 09, 2019 12:23 am
I used to save preferences in plugin stacks instead of text files before I wised up.
I often do the same, but I wasn't the original author of this plugin, and so far have only changed enough of it to bring it up to the current IDEs.
When I work on these older things, my approach is to change as little as I can for a number of reasons, the primary one being I am sure I don't know as much as the people who wrote them originally did, and the secondary being that I don't like releasing things that act screwy because of something I might have missed (like this very thing we are talking about, heh).
Just to make sure I am parsing the situation correctly, unless a 'save' is issued explicitly somewhere within a stack, nothing in the IDE or engine changes the stack format? Cause I always thought it did.
I think part of my misunderstanding how it all works comes from 2 sources, one being that when you say, are working in the IDE and have a stack and you type in fields, the fields are saved (making me think some kind of save is going on somewhere), and the second confusing source was this
lesson, which tells you to use
Code: Select all
on closeStack
save this stack
pass closeStack
end closeStack
to save the cProp, which made me think the IDE was doing the same (somewhere along the way).
Only problem is, (I think), since I added the ability for the plugin to create new cards for people to put their own tips into, would that get flubbed up if the stack doesn't save itself? Now I am dying to know
Thanks again for finally punching that concept through my skull, which is often thicker than
UN-OBTAINIUM 
mwieder wrote: Tue Jul 09, 2019 12:23 am
The browser widget and linux don't play well together ever since LC went the CEF route.
In this case, unless the browser widget is somehow running at all times, I don't think that is the problem. I have had versions that showed no attempt to start at all (no splash or other sign they were starting). There have been versions that blipped out on opening the code editor. On placing a field. On placing *any* widget, such as trying to follow the bmi tutorial. The list goes on and on and on.
Mind you, I never have these experiences in the older versions, although I do get other interesting issues in the earliest ones, they haven't been show stoppers.
So, when a new release comes out, I download it and see how it acts, but there are other problems because I specifically don't use one of the 'chosen' release distros. Let's assume I download and rigorously test RC x.
None of my testing will solve anything, because the distro isn't supported. So now I have to create a vm to hold a distro that is supported to see if the same problem happens on that one (which it doesn't the majority of the time).
That is all well and good, but it takes time I usually don't have to begin with for now, and screws up my train of thought on whatever I was initially doing to begin with, for something I don't plan to be using anytime soon anyway.
None of the above stops me from doing testing on the new releases when I do have spare time, but they sure aren't my primary turn to item for development to begin with since I haven't seen anything I need to get done I can't do with the 2.4 set of engines which all apparently work pretty well on a wide range of boxes I still work with.
I am just weird I guess, or maybe an anachronism snowflake
