- Wed Dec 28, 2016 6:31 am
#60051
mariolatronico,
CSS styles should each have a colon separating the name from the value, and a semicolon to end the entry, eg: style="name:value; "
Omitting anything leaves the statement incomplete and liable to cause problems.
Rather than repeatedly calling cssid function several times each with 1 parameter, you might get better results by combining all the required style parameters (each separated by ";") into 1 cssid call, thereby reducing several lines of code into just one.
It might also be convenient to add the parameters into a re-usable variable, ie: var = "par1: val1; par2: val2;", then invoke with 'cssid var'. This also allows style strings greater than would fit on a browser line by appending using var = var & "much more".
So for instance your styles above could be done as:
Trying to include a line break <BR> (or any non-text char) into a buttons "name" seems to be skating on very thin ice and asking for trouble!
Your stated:
The following code can to help track down memory leaks.
The first 'commented-out' line enables or disables the memory guage.
The max (guage right-hand) value is obviously only available immediately after the 'memfree' clearout, therefore available mem can be expected to progressively reduce with every variable that is declared etc, after which it should stabilise around some 'mean' level.
***EDIT***
The memory guage can then be displayed using...
You should add additional 'memfree = ramfree()' lines wherever you wish to 'peek' at available remaining memory, ie: just before any 'wait' instructions etc.
A memory leak will keep reducing available mem until it causes a crash, so I included mem guage 'min' with the intention of having a lower minimum threshold which could trigger a controlled Esp reboot to pre-empt a crash.
However my 'crashing' problems seemed to arise from filling up the 'screen buffer' rather than actually running out of ram due to a memory leak, which seemed to suggest that available ramfree() memory and remaining buffer size may not be directly related.
For trouble-shooting, rather than deliberately and inevitably filling the screen buffer by keep sending all diag msgs to screen, msgs can either be sent using serialprinln to the serial monitor (preferably one with a 'CLEAR' button to remove previous clutter) or udpwrite them to cicciocb's udp debugger utility or similar.
Or you can send them to screen by over-writing the previous message rather than keep adding new messages, eg:
Then add appropriate 'debugmsg="myinfo"' lines wherever wished.
Obviously only the last read 'debugmsg=' will appear in the debug message window, so delete or comment out unwanted 'debugmsg=' messages... and you might find it helpful to include relevent branch names in the debug msgs so you can quickly find them again when needed.
CSS styles should each have a colon separating the name from the value, and a semicolon to end the entry, eg: style="name:value; "
Omitting anything leaves the statement incomplete and liable to cause problems.
cssid chMyColorID, "font-size: 24px"
cssid chMyColorID, "border-radius: 10px"
cssid chMyColorID, "border: 10px solid silver"
cssid chMyColorID, "background-color: silver"
cssid chMyColorID, "border-style: outset"
Rather than repeatedly calling cssid function several times each with 1 parameter, you might get better results by combining all the required style parameters (each separated by ";") into 1 cssid call, thereby reducing several lines of code into just one.
It might also be convenient to add the parameters into a re-usable variable, ie: var = "par1: val1; par2: val2;", then invoke with 'cssid var'. This also allows style strings greater than would fit on a browser line by appending using var = var & "much more".
So for instance your styles above could be done as:
Code: Select all
mystyle = "border-radius: 10px; border: 10px solid silver; background-color: silver;"
mystyle = mystyle & "border-style: outset;"
cssid mystyle
button "Toggle <BR> PO0", [tglPO0]
Trying to include a line break <BR> (or any non-text char) into a buttons "name" seems to be skating on very thin ice and asking for trouble!
Your stated:
Function is OK for some click before crashcould suggest the script is suffering from memory leakage, typically caused by branch calls not being returned from correctly and therefore causing the likes of a 'stack overflow' crash.
The following code can to help track down memory leaks.
Code: Select all
memclear
'memguage = "y" 'Un-comment to enable memory guage
if memguage = "y" then
max = ramfree()
min = 1000
memfree = ramfree()
endifThe first 'commented-out' line enables or disables the memory guage.
The max (guage right-hand) value is obviously only available immediately after the 'memfree' clearout, therefore available mem can be expected to progressively reduce with every variable that is declared etc, after which it should stabilise around some 'mean' level.
***EDIT***
The memory guage can then be displayed using...
Code: Select all
if memguage = "y" then
html |<table style="width:100%;margin:auto;text-align:center;">|
html | <tr style="top-padding:0px;bottom-padding:0px;">|
html | <td style="text-align:left;color: red;">1000 min </td>|
html | <td style="color:orange;text-align:center;">avail |
textbox memfree
cssid htmlid(), "color:black;text-align:center;"
html |</td>|
html | <td style="text-align:right;color:green;">max | & max & |</td>|
html | </tr>|
html |</table>|
meter memfree, min, max ' *************** MEMORY METER *******************
cssid htmlid(), "width:100%; height:10px; color:red; background-color:blue;display:block;"
endif
You should add additional 'memfree = ramfree()' lines wherever you wish to 'peek' at available remaining memory, ie: just before any 'wait' instructions etc.
A memory leak will keep reducing available mem until it causes a crash, so I included mem guage 'min' with the intention of having a lower minimum threshold which could trigger a controlled Esp reboot to pre-empt a crash.
However my 'crashing' problems seemed to arise from filling up the 'screen buffer' rather than actually running out of ram due to a memory leak, which seemed to suggest that available ramfree() memory and remaining buffer size may not be directly related.
For trouble-shooting, rather than deliberately and inevitably filling the screen buffer by keep sending all diag msgs to screen, msgs can either be sent using serialprinln to the serial monitor (preferably one with a 'CLEAR' button to remove previous clutter) or udpwrite them to cicciocb's udp debugger utility or similar.
Or you can send them to screen by over-writing the previous message rather than keep adding new messages, eg:
Code: Select all
'debugmode = "y" 'Un-comment to enable debug messages
if debugmode = "y" then
debugmsg = ""
textbox debugmsg
endif
Then add appropriate 'debugmsg="myinfo"' lines wherever wished.
Obviously only the last read 'debugmsg=' will appear in the debug message window, so delete or comment out unwanted 'debugmsg=' messages... and you might find it helpful to include relevent branch names in the debug msgs so you can quickly find them again when needed.
