How to clear an element before ElemSetTxtStr (remove old text) #404
-
Hi When I update an element with ElemSetTxtStr, if the old text was longer or 'taller' than the new text, then there are remnants of the old text even after the element is updated. I have tried setting the element to blank spaces (i.e. in a 5 length element " ") but this does not work as I want (to clear the element completely) unfortunately. Thank you. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
@PrattTechnologies If you add a zip file of a small sample project that reproduces your problem it makes coming up either what you are doing wrong or with a bug fix to GUIslice easy. Just drag and drop the zip file anywhere in a new comment or answer. If the discussions section doesn't work you may need to repost in the issues section to attach files. |
Beta Was this translation helpful? Give feedback.
-
GUIslice should redraw the entire text widget if you call ElemSetTxtStr(). What you describe might suggest that your new text is larger than the size of the text widget specified in the Builder (assuming you are using the Builder). I would first try to increase the size of the text field in the Builder to match the largest string that you might set via ElemSetTxtStr(). As Paul suggests, attaching your project will help us determine what your code may be doing. From that, we should be able to infer the text strings that are being passed into ElemSetTxtStr(). thx |
Beta Was this translation helpful? Give feedback.
-
@PrattTechnologies @ImpulseAdventure Well, I couldn't reproduce your problem but I found enough bugs in your program to point to possible issues. 1- You must call gslc_Update every cycle through loop() or your UI will become unresponsive. Also, you need a delay in loop() to show all messages received or you will only see the last full message.
2- Inside serailRead you fail to terminate your message buffer during initalization so it will have garbage inside it and if it gets displayed you will see the results you posted. 3- Your read loop as written can over-write your message buffer because you have no guard in place (i<4). 4- Now while you do have a snprintf of 4 you don't actually need to terminate your message buffer on each cycle so it not really a bug but its always good practice to do so anyway. That's up to you. In the sample code below I do so just to display in the serial monitor what is happening on each read. Now one real bug here is your snprint is set to 4 and it should be 5. So in summary I would code your seriallRead() as:
Now, If these changes still leave you with a problem its possible its your font size. Increase the height and width of your m_pElemInput. From 91,26 to larger values say 110, 40 If all of this fails then I'm sorry but you will need help from Calvin. This is as far as I can go. |
Beta Was this translation helpful? Give feedback.
-
@PrattTechnologies One last point I forgot to mention. You don't need to do a snprint to acTxt. Simply:
Since inside your debug_GSLC.h the gslc_ElemCreateTxt() call set the max size of its buffer and will not allow any overwrite. |
Beta Was this translation helpful? Give feedback.
@PrattTechnologies @ImpulseAdventure Well, I couldn't reproduce your problem but I found enough bugs in your program to point to possible issues.
1- You must call gslc_Update every cycle through loop() or your UI will become unresponsive. Also, you need a delay in loop() to show all messages received or you will only see the last full message.
2- Inside serailRead you fail to terminate your message buffer during initalization so it will have garbage inside it and if it gets displayed you will see the results you posted.
3- Your read loop as written can over-write your m…