Corona IDE

I figured what happened; the Watch window is using caret line background color to mark those items that just changed. It wasn’t such a good idea to use this as it can be dark as you noticed. I’ll need to change it to something else…

Paul.

@Paul,

Yup - Copying that block of script fixed my problems!  Thanks!

@gamedeveloper, I pushed a change that should fix this issue. Let me know if this works for you. Paul

@gamedeveloper

Developing on 13’ monitors is a nasty thing with such a limited editor panel size.

Is it possible for the output window (the “bottomnotebook” in src/editor/gui.lua) to become an auto-hide window? Hidden when editing code and visible when in debug/run mode, like in Sublime for example.

Thanks!

@Magenda, it almost does this. In fact, you have several options to maximize the screen space:

(1) You can hide the output window using Ctrl-Shift-O/Cmd-Shift-O and it will be restored when there is a new output to it.
(2) You can undock the output panel and put it in the right/bottom corner to make it take less space.
(3) You can also use Full-Screen/Zen mode (Ctrl-Shift-A/Cmd-Shift-A) to get the maximum screen space when editing; this will hide all the panels except the editor tabs.

I’ve got an interesting problem with ZeroBrane. When I start the debugging it starts up the simulator just fine but it does not hit any breakpoints.

If I make any changes to main.lua, save, close ZeroBrane and then open it again it shows that the changes stuck and that the file was saved… However, the changes do not appear in the simulator and on closer inspection the file that I edited when opened in Notepad shows that it was never changed.

All my settings seem correct and I followed the Corona tutorial to the letter. I’m running Windows 8 and I installed ZeroBrane to the default directory.  I have no idea what the problem can be.

@summergoth, this usually only happens when the file name reported by the Lua engine (in Corona) doesn’t match the file name seen by the IDE. Make sure you set the project directory correctly (“Project | Project Directory”); you may use “Set from Current File” if your current file is main.lua.

> If I make any changes to main.lua, save, close ZeroBrane and then open it again it shows that the changes stuck and that the file was saved… However, the changes do not appear in the simulator and on closer inspection the file that I edited when opened in Notepad shows that it was never changed.

I agree, this is very strange. The only thing that comes to mind (and I know, this is silly, but) is to check if you are editing in ZBS the same file you are opening in Notepad. You can also check if you see changes in your lua file after you close ZBS.

What *may* be happening (and it may explain both of the issues) is that you edit main.lua in one location, but your project points to a different location. For example, your project folder points to “a/b” folder, which has main.lua, but you actually edit “d/e/main.lua” file. When you Run/Debug, your project, it actually opens Corona using “a/b/main.lua” (as ZBS does this based on the project setting), which means that the breakpoints are not going to work (as you set them for “d/e/main.lua”). It’s also explain why you don’t see the changes in the Simulator.

Thanks for the reply paulclinger6.  I made sure that the project directory is set and it was definitely the same file.

This morning though, I got it to work! :slight_smile: I downloaded the zip file instead of the installer hoping it would make a difference and it did not.  As a last resort I tried running the program as Administrator and that worked!  I should have tried it from the beginning.

So yes, I just set it to always run with Administrator privelages and now it works perfectly.

It’s a great IDE and thank you for making it available to us. Hopefully if all goes well I will give you a deserved donation.

I have a problem with seeing error output from the simulator. I can use the debugger and see all the petty printed output, but no console window or alike.

I have been able to “fix” it by having Outlaw in the background and using that to launch the simulator (it opens a console window which shows the errors).

Suggestions?

And yes; I´m testing ZBS under win7… :slight_smile:

Glad to hear you got it working! I wanted to make sure ZBS can be used with regular accounts and even signed the executable to avoid issues like this, but I guess in some cases it’s still not enough. Paul.

@renato.bugge, yes, you should be able to see the errors from the simulator in the Output window when you do debugging. For example, if I add “foo()” call to one of the sample scripts, I get an error like this in the Output window:

…ample code\gettingstarted\timeanimationlive\main.lua:8: attempt to call global ‘foo’ (a nil value)
stack traceback:
[C]: in function ‘foo’
…ample code\gettingstarted\timeanimationlive\main.lua:8: in main chunk

However, if you “Run” the project and don’t use ‘require(“mobdebug”).start()’, then you indeed won’t see the output. For some reason the simulator behaves this way on Windows (it works as expected on OSX). The console is hidden by default, but you can “unhide” it, which will allow you to see all the messages: (1) open file interpreters\corona.lua from ZBS, (2) find “CommandLineRun” call (around line 63), (3) change its 4th parameter from false to true.

@gamedeveloper

Developing on 13’ monitors is a nasty thing with such a limited editor panel size.

Is it possible for the output window (the “bottomnotebook” in src/editor/gui.lua) to become an auto-hide window? Hidden when editing code and visible when in debug/run mode, like in Sublime for example.

Thanks!

@Magenda, it almost does this. In fact, you have several options to maximize the screen space:

(1) You can hide the output window using Ctrl-Shift-O/Cmd-Shift-O and it will be restored when there is a new output to it.
(2) You can undock the output panel and put it in the right/bottom corner to make it take less space.
(3) You can also use Full-Screen/Zen mode (Ctrl-Shift-A/Cmd-Shift-A) to get the maximum screen space when editing; this will hide all the panels except the editor tabs.

I’ve got an interesting problem with ZeroBrane. When I start the debugging it starts up the simulator just fine but it does not hit any breakpoints.

If I make any changes to main.lua, save, close ZeroBrane and then open it again it shows that the changes stuck and that the file was saved… However, the changes do not appear in the simulator and on closer inspection the file that I edited when opened in Notepad shows that it was never changed.

All my settings seem correct and I followed the Corona tutorial to the letter. I’m running Windows 8 and I installed ZeroBrane to the default directory.  I have no idea what the problem can be.

@summergoth, this usually only happens when the file name reported by the Lua engine (in Corona) doesn’t match the file name seen by the IDE. Make sure you set the project directory correctly (“Project | Project Directory”); you may use “Set from Current File” if your current file is main.lua.

> If I make any changes to main.lua, save, close ZeroBrane and then open it again it shows that the changes stuck and that the file was saved… However, the changes do not appear in the simulator and on closer inspection the file that I edited when opened in Notepad shows that it was never changed.

I agree, this is very strange. The only thing that comes to mind (and I know, this is silly, but) is to check if you are editing in ZBS the same file you are opening in Notepad. You can also check if you see changes in your lua file after you close ZBS.

What *may* be happening (and it may explain both of the issues) is that you edit main.lua in one location, but your project points to a different location. For example, your project folder points to “a/b” folder, which has main.lua, but you actually edit “d/e/main.lua” file. When you Run/Debug, your project, it actually opens Corona using “a/b/main.lua” (as ZBS does this based on the project setting), which means that the breakpoints are not going to work (as you set them for “d/e/main.lua”). It’s also explain why you don’t see the changes in the Simulator.

Thanks for the reply paulclinger6.  I made sure that the project directory is set and it was definitely the same file.

This morning though, I got it to work! :slight_smile: I downloaded the zip file instead of the installer hoping it would make a difference and it did not.  As a last resort I tried running the program as Administrator and that worked!  I should have tried it from the beginning.

So yes, I just set it to always run with Administrator privelages and now it works perfectly.

It’s a great IDE and thank you for making it available to us. Hopefully if all goes well I will give you a deserved donation.

I have a problem with seeing error output from the simulator. I can use the debugger and see all the petty printed output, but no console window or alike.

I have been able to “fix” it by having Outlaw in the background and using that to launch the simulator (it opens a console window which shows the errors).

Suggestions?

And yes; I´m testing ZBS under win7… :slight_smile:

Glad to hear you got it working! I wanted to make sure ZBS can be used with regular accounts and even signed the executable to avoid issues like this, but I guess in some cases it’s still not enough. Paul.

@renato.bugge, yes, you should be able to see the errors from the simulator in the Output window when you do debugging. For example, if I add “foo()” call to one of the sample scripts, I get an error like this in the Output window:

…ample code\gettingstarted\timeanimationlive\main.lua:8: attempt to call global ‘foo’ (a nil value)
stack traceback:
[C]: in function ‘foo’
…ample code\gettingstarted\timeanimationlive\main.lua:8: in main chunk

However, if you “Run” the project and don’t use ‘require(“mobdebug”).start()’, then you indeed won’t see the output. For some reason the simulator behaves this way on Windows (it works as expected on OSX). The console is hidden by default, but you can “unhide” it, which will allow you to see all the messages: (1) open file interpreters\corona.lua from ZBS, (2) find “CommandLineRun” call (around line 63), (3) change its 4th parameter from false to true.

Hey paul, any way you can add variable saving? (kinda like in TextMates that it saves the variables you write and it’s easier to get them after…

I like ZeroBrane so far! Great job!