This topic contains 8 replies, has 3 voices, and was last updated by Hanno .
January 17, 2012 at 2:25 pm #10668
I’m having a problem. When I load a new program and manually add the OBJ and vp.share() statements, no variables show up in VP, and no debugging works. But when i loaded one of the tutorials that worked, then closed it all out, then opened my program and tried to debug it, I had the shared variables a,b,c etc from the tutorial program persistently showing up in VP (but not being populated) and not mine. I could not make them go away. The config kept showing these non-existent variables and never the ones I was sharing. Before that it was stuck on the claim I had 400 variables, though that was in a previous config when I tried to share the frame buffer. So it looks like now I have a blank config and I’m stuck with that one.
I suspect it has something to do with the fact the program installed under an admin account and there is now a problem accessing AppData/local/VirtualStore/ files.January 19, 2012 at 4:32 am #11741
Very odd, I can’t reproduce your problem. Here is what I do:
"debug>start debugging" This switches to debug mode and shows me the variables as configured in the included "viewport configuration.spin"
"file>open" (01 four big..)
"debug>start debugging" Shows me new set of variables
HannoJanuary 19, 2012 at 6:10 am #11742
Yes, the examples work fine, and variables get updated. If I start modifying one of the examples, it will not change to these new variables.
I’m scratching out a workaround by copying Configuration strings from the Configuration dialog. If I start from scratch, the File->Configuration menu brings up a dialog where I cannot Add a Control, so I’m stuck. If I start with a working example, then I can add and modify Controls, then if I copy and paste the config into my program it works a lot better. But if I rely on it doing it by itself, nada.
I see VP proposes to save the config in Program Files(86), which under current windows standards is supposed to be read-only, never a legit place for a program’s preferences, or a user’s files. All that stuff must go in the user’s AppData folder. It’s like the old .ini files that went in the protected /Windows directory, and now cannot work there. Windows will virtualize files that are written to protected folders, even if you’re running in an admin account, and then access rights get complicated. So anyway, I think it has something to do with where you are storing .cfg files. Hardware-oriented users may be running Windows with all security disabled/bypassed so the problem doesn’t show up? Are you running under a normal User account, or as Admin?
Even if I start with an old working tutorial, get the Configuration dialog to where it allows Adding controls, then paste config code into my code, there are still odd things happening, like adding the vp. code changes the behavior of my code. Like Byte variables are taking on word values. Also at the moment it’s Terminal that’s not working.
OK, hours later, I’m chasing two issues. One is the config one above. I can work around it as above, but the problem is still there. The second is that calling Terminal methods isn’t sending anything to the Terminal window, and is corrupting my code’s variables, be they global, or local.January 19, 2012 at 8:07 am #11743
Thanks, Hanno. Nothing like a call from Tomorrow. Still don’t knows what that config issue is/was, but it can be circumvented for now, and 4.6.7 solves the Terminal corruption problem.February 6, 2012 at 2:01 am #11744
I have the exact same problem with ‘Run’ not working until I’ve run a sample file, then the Terminal isn’t clearing, and continues to display the ‘old’ variables**, and not outputing to the Terminal window.
There also seems to be a mix of conflicting information in the Help files, tutorials, PDF files and on the web pages.
Part of my problem is when lines like these are included…
vp : "Conduit", or
vp : "ViewPort Configuration", or
These three OBJ are from various library files but I can’t use them in my source code like they are in the samples. These all need to be given different nicknames, such as vpConfig, vpTerm and vpConduit.
** These old variables don’t clear even when ViewPort is closed down, then restarted with only MY program.February 10, 2012 at 3:54 am #11745
I have another problem. Occasionally the text is becoming corrupted for some reason.
If you go to http://obex.parallax.com/objects/413/ and download the object (It’s the "Text based GUI for VGA_HiRes_Text Driver (revised)" one.)
Open the GuiDemo.spin file,
Using Propeller tool, Search for this line…
GUI.ClearScreen( %%020, %%000 ) ‘green on black each is %%RGB 4 levels per R-G-B
now do the same thing with ViewPort, you get something different, but if you cut and paste, it’s normal!
GUI.Clearscreen(%%020, %0 0 ‘gre n n bla k ea h s %%R B leve s p r R-G <– Typed as seen on the screen
GUI.ClearScreen( %%020, %%000 ) ‘green on black each is %%RGB 4 levels per R-G <– Cut and pasted from VP.
Unfortuneately, VP sees what I see and doesn’t like the first line.
I’m using VP 4.6.7.
Any ideas?February 10, 2012 at 10:45 am #11746
Very interesting! Thanks for letting us know, a big update is coming this week, will try to include fixes for both these issues.
HannoFebruary 10, 2012 at 4:28 pm #11747
Thanks Hanno, I look forward to the update.February 14, 2012 at 7:19 am #11748
Update is almost here, nothing is ever as easy as I think it is
Just wanted to point out that only 1 object should be included to interface with ViewPort.
-If you’re doing little "terminal" debugging and mainly want to view/edit variable values, then use the "conduit" object.
-If you need more terminal functionality to parse incoming numbers and output hex or decimal numbers then use the "terminal" object, it’s a direct superset of "conduit".
-If you want to place ViewPort functionality into a separate file like "vp configuration" then include that one, I advise against it.
Clear as mud?
You must be logged in to reply to this topic.