It’s possible to SET DEBUG ON and SET DEBUGTRACE ON when running from the App Center. Simply add it someplace like the Init delagate for the App. That way you’ll at least get the debug files.
try deleting any .dbo files from your app’s directory and the ./library/ directory and see if that changes the behavior.
Try adding a LIST STATUS TO FILE <filename> before the MESSAGEBOX() and see if everything in there is as you expect.
Have you tried issuing SET DEBUG ON and checking the log in the ./debug/ directory for more information? Issue it in the console before you open your app.
If you could SET DEBUG ON, make your ODBC connection from the console, USE this table, then post the resulting debug file
Can you switch to the lib_search.prg tab in the debugger?
If there is an error in search.rsp, there should be an errorxxxx.mem in lianja\error.
If you open the script in the Script Editor, you can click the Debugger button in the Headerbar to load it into the Debugger.
It appears that the app debugger (icon in IDE left bottom) is only for debugging Recital script pages (prg?)
yes, the full Desktop App ‘Debug’ debugger is for debugging Lianja/VFP scripts.
switch debug on in the Console Workspace Lianja/VFP Command Window:
set debug on
Then open an App and attempt an update.
Then in the Console Workspace, Lianja/VFP command window:
If you are debugging an App, just load the App and click the ‘Debug this App’ button in the ModeBar. This will automatically load any custom libraries referenced by the UI Controls. For example, in the lianjacustomcanvas App included in the Lianja App Builder distribution, the ‘page1’ Page references lib_page1.prg and the ‘section2’ Section references lib_page1_section2.prg.
I’ve created a program called myfunc.prg and it is referenced from lib_page1_section2.prg. If I want this to be loaded along with the custom libraries when I open the Debugger, I open it in the Script Editor in the Apps Workspace and click the ‘Open file in Debugger’ button:
Now when I click the ‘Debug this App’ button in the ModeBar, myfunc.prg is also immediately available in the Debugger, not just when it is called while the Debugger is active and ‘Step Into’ used.
With my ‘myfunc.prg’ program loaded in the Debugger, I can set Watch and Break points and continue running the App until one of these is reached.
I click next to the line number to make a line a Breakpoint:
And select/highlight the name of a variable then click ‘Watch’ to set a Watchpoint on a variable:
I can then run the App and the Debugger activates when a Breakpoint or Watchpoint is reached:
You can enable debugging for the Lianja App Center as follows (please remember to switch it off after you’ve tracked down the error):
Create a text file called ‘config.db’ in C:\Lianja\conf and edit it to contain the line
set debug on
This is the equivalent of setting debug on from the Console Workspace in the Lianja App Builder, so check for any information logged into C:\Lianja\debug\*.txt.
I should also mention that that will be a system-wide setting while enabled – so will also apply to a Lianja App Builder on the same machine.
In the Console, switch debug logging on:
set debug on
Then do your updates, exit the App Builder and have a look at the files in Lianja\debug to see if any errors are reported.
Can you put a LIST STATUS just before that to show what tables are already open?
Specify a target for the SELECT – at the moment it will just be going to the Console Output Window as standard output.
For example, save it to a cursor:
SELECT PENALTYDESC ; FROM bantam_stats!penalties ; WHERE teamid = intTeamID AND playernumber = intPlayerNumber; into cursor cPenalties messagebox(penaltydesc)
or into a memory variable:
SELECT PENALTYDESC ; FROM bantam_stats!penalties ; WHERE teamid = intTeamID AND playernumber = intPlayerNumber into cPenaltydesc messagebox(cPenaltydesc)
You can use Lianja.writeOutput() then open the app inspector, switch to runtime mode then look in the events tab and the output.
when you SET DEBUG ON in the console, you can look in the c:\lianja\debug\debug_client.txt file which has a trace of all property set/get and method calls. It can help to identify problems.
Also if you
SET DEBUGOUT ON
DEBUGOUT "some message"
these will be included in the debug,txt file also which should help to track the problem down.
Try this in the console:
Or close the App and this in the Debug Console:
To see how events are being dispatched, in the console workspace type:
SET EVENTTRACKING ON
then you can look in c:\lianja\debug\debug_client.txt to see if the events are being dispatched or not.
Not wanting to sound like a broken record, but if you SET DEBUG ON and run you code then exit Lianja and look in the debug_client.txt file you will be able to see if the object was destroyed and the ActiveX destroyed alongside it.
Try assigning .f. To it rather than .null.
if you are having difficulties getting this to work then SET DEBUG ON and test your update. If it does not work look in debug_client.txt. If you can’t figure it out then submit a ticket attaching debug_client.txt, the output from LIST STATUS in the console and your delegate code that is performing the update.
Open up the App Inspector and watch the events at runtime when you open the App with Lianja.openApp().
The console is designed to run interactive single line commands.
The simplest way to write complete multi-line scripts in the console is to type:
You will now be in the script editor where you can type in as much as you want.
next, just select the “Console” workspace (no need to save it is done automatically) then type:
You can’t debug complied server pages which is what you are trying to do.
Server pages ( .rsp pages ) are just in time compiled producing a .rso object file which is executed.
Ok so that’s a virtual table you are relating to?
will tell you the alias names which are referenced in the relationship and show you the column names.
Look in the console and see if there are any errors, also LIST STATUS will show what indexes were created to handle the related sections.