This releases the invokeAndBlock thread more often and reduces the period the monitor is held. Honestly, I'm not sure if it's a good fix though.
On Wednesday, November 25, 2020 at 12:18:18 PM UTC+2 P5music wrote: > I see that a modification has been made to a file about the issue I opened: > https://github.com/codenameone/CodenameOne/issues/3300 > I am curious about what's the meaning and the gist of that modification: > > https://github.com/codenameone/CodenameOne/commit/ceccd47bdcc3dd3c8f836ec53c10a0fcd3827814 > if you may explain it to me. > Furthermore I see that some days ago another modification has been made: > > https://github.com/codenameone/CodenameOne/commit/8f847a45e19de2dbac3bf86e9fcd93d5761471cf > I think it could be related to my issue too. Am I right? > What can be done? Where I could study this problem on source code? > Thanks in advance > Regards > Il giorno martedì 3 novembre 2020 alle 21:06:04 UTC+1 P5music ha scritto: > >> Only execute() is used, and moreover that methods and the dialog method >> correctly return, nothing is blocked in debugging mode. It has to be >> something internal. >> Indeed I created a test case with no Javascript execution at all. >> Javascript is not causing the BrowserComponent to block (in the simulator). >> See the attached file. It is from a bare-bone app. A button launches a >> blocking dialog. Also another dialog is launched at startup that's not >> blocking. >> You cannot select text inside the BC after you launch the blocking dialog. >> Thanks >> Il giorno martedì 3 novembre 2020 alle 13:44:34 UTC+1 Steve Hannah ha >> scritto: >> >>> Hard to say from just that code. In general, try to use >>> invokeAndBlock() sparingly as it comes with a cost, and may not behave the >>> way you expect in cases where there are multiple blocking calls >>> overlapping. Dialog uses invokeAndBlock for showDialog(). If you're using >>> any "xxxAndWait()" methods in the BrowserComponent, those use >>> invokeAndBlock also. >>> >>> >>> >>> On Tue, Nov 3, 2020 at 1:19 AM 'P5music' via CodenameOne Discussions < >>> [email protected]> wrote: >>> >>>> Found the culprit. It was not Javascript, it was not JSON, >>>> >>>> it was Dialogs. >>>> At the completion of an import feature in my app a dialog is shown. I >>>> created a class with static methods that handle dialogs. A method like the >>>> one below causes the blocking of the BrowserComponent. In another >>>> container >>>> (it's a sort of master/detail layout) another BC is also blocked, but not >>>> the TextFields for example. >>>> Here's the method: >>>> public static void openAlertDialog( String s1, String s2) >>>> { >>>> Dialog alertDialog=new Dialog(s1); >>>> Button okButton=new Button(okCommand); >>>> alertDialog.setLayout(BoxLayout.y()); >>>> Container c1=new Container(); >>>> c1.setLayout(BoxLayout.x()); >>>> alertDialog.add(new SpanLabel(s2, "DialogBody")); >>>> c1.add(okButton); >>>> alertDialog.add(c1); >>>> alertDialog.showDialog(); >>>> } >>>> The dialog closes as expected but as I can understand I forgot some >>>> closing/unblocking instruction. >>>> Is that it? >>>> Il giorno martedì 3 novembre 2020 alle 04:31:24 UTC+1 Shai Almog ha >>>> scritto: >>>> >>>>> Try thinking how the test case differs from your actual >>>>> implementation. I'll ask Steve if he has an idea. >>>>> >>>>> On Monday, November 2, 2020 at 10:48:29 PM UTC+2 P5music wrote: >>>>> >>>>>> I checked it out and it is true, BCs get stuck together >>>>>> but >>>>>> it is not Javascript fault. >>>>>> >>>>>> I stripped away all lines of code step by step >>>>>> and so just it seems to be a problem caused by JSON reading json text >>>>>> with json array inside, or something related to ArrayLists, or creating >>>>>> instances of a certain class from json array elements. >>>>>> >>>>>> The strange thing is that the JSON array is correctly extracted and >>>>>> all is completed with no errors, data are created correctly >>>>>> but after it the BC is stuck. >>>>>> >>>>>> If I comment that methods that has JSON import inside the BC is not >>>>>> blocked. >>>>>> >>>>>> As I can understand something is causing a silent crash inside the >>>>>> simulator (?!?). >>>>>> I created a test case but it Does work, so I cannot reproduce the >>>>>> issue, indeed the BC is Not blocked. >>>>>> >>>>>> I have no means to further debug my app. >>>>>> >>>>>> >>>>>> >>>>>> Il giorno lunedì 2 novembre 2020 alle 03:54:16 UTC+1 Shai Almog ha >>>>>> scritto: >>>>>> >>>>>>> AFAIK they all use a single browser engine and are as a result >>>>>>> single threaded. If JS in another component is blocking (or a >>>>>>> navigation >>>>>>> listener) then there could be cascading effects. >>>>>>> >>>>>>> On Sunday, November 1, 2020 at 3:46:22 PM UTC+2 P5music wrote: >>>>>>> >>>>>>>> That error was a one-time event, I think. >>>>>>>> In fact the Javascript code is executed, for examples commands like >>>>>>>> this: >>>>>>>> var div=document.createElement('DIV');div.innerText="TEXT >>>>>>>> INJECTED";div.style.position="relative";div.id >>>>>>>> ="0";document.body.appendChild(div); >>>>>>>> but then the BC is stuck. >>>>>>>> Do you deem that another BC elsewhere in the application with other >>>>>>>> Javascript injection could cause this? Have the BCs something in >>>>>>>> common >>>>>>>> that can be cross-locked? >>>>>>>> Il giorno domenica 1 novembre 2020 alle 03:28:13 UTC+1 Shai Almog >>>>>>>> ha scritto: >>>>>>>> >>>>>>>>> Yes that could be relevant. >>>>>>>>> Can you update the Codename One libraries via Codename One >>>>>>>>> Settings and try to reproduce this? >>>>>>>>> That line number is no longer applicable. >>>>>>>>> >>>>>>>>> On Saturday, October 31, 2020 at 4:10:38 PM UTC+2 P5music wrote: >>>>>>>>> >>>>>>>>>> I do not see Javascript errors in Chrome (previously, syntax >>>>>>>>>> errors where shown and I fixed them, now there is nothing) >>>>>>>>>> But I see this error in log, could it be relevant? >>>>>>>>>> Exception in thread "Thread-154" java.lang.NullPointerException >>>>>>>>>> at >>>>>>>>>> com.codename1.impl.javase.cef.ResourceHandler.getResponseHeaders(ResourceHandler.java:39) >>>>>>>>>> Il giorno sabato 31 ottobre 2020 alle 06:04:48 UTC+1 Shai Almog >>>>>>>>>> ha scritto: >>>>>>>>>> >>>>>>>>>>> Have you tried the chrome JavaScript debugger to see where it's >>>>>>>>>>> stuck? >>>>>>>>>>> Just inject some event code to see where things are blocked and >>>>>>>>>>> see if breakpoints are reached. >>>>>>>>>>> >>>>>>>>>>> On Friday, October 30, 2020 at 9:30:16 AM UTC+2 P5music wrote: >>>>>>>>>>> >>>>>>>>>>>> I realized that the executeAndWait call came from myApp, but in >>>>>>>>>>>> another BC that's in another container. >>>>>>>>>>>> Now all calls are of the execute() type. >>>>>>>>>>>> >>>>>>>>>>>> I debugged and I see that the calls are completed and the app >>>>>>>>>>>> runs again. >>>>>>>>>>>> So the BC is not blocked by the Javascript injection. >>>>>>>>>>>> >>>>>>>>>>>> I created a test case but I see that this blocking does happen >>>>>>>>>>>> only in my app. >>>>>>>>>>>> >>>>>>>>>>>> What further debugging is possible, said that the execute() >>>>>>>>>>>> method seems not to the cause? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Il giorno venerdì 30 ottobre 2020 alle 07:06:54 UTC+1 Shai >>>>>>>>>>>> Almog ha scritto: >>>>>>>>>>>> >>>>>>>>>>>>> executeAndWait uses invokeAndBlock to wait. That means that >>>>>>>>>>>>> the JavaScript call never completed. >>>>>>>>>>>>> Since this happens in the simulator it's pretty easy to place >>>>>>>>>>>>> a breakpoint on executeAndWait to find out who invoked it. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, October 29, 2020 at 11:03:17 AM UTC+2 P5music >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that it is stuck repeating here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> while (!res.complete) { >>>>>>>>>>>>>> Display.getInstance().invokeAndBlock(new Runnable() { >>>>>>>>>>>>>> >>>>>>>>>>>>>> public void run() { >>>>>>>>>>>>>> Util.wait(res, 1000); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> }); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> in executeAndWait. >>>>>>>>>>>>>> Notice that in my app this method is not called, instead the >>>>>>>>>>>>>> normal execute() is. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Il giorno giovedì 29 ottobre 2020 alle 04:25:43 UTC+1 Shai >>>>>>>>>>>>>> Almog ha scritto: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't know. We'll need to see an issue in isolation in the >>>>>>>>>>>>>>> issue tracker to debug this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wednesday, October 28, 2020 at 11:02:11 AM UTC+2 P5music >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No errors in JS console. >>>>>>>>>>>>>>>> Could it be possible that the execute() instruction is >>>>>>>>>>>>>>>> waiting for some call like onSuccess() ? >>>>>>>>>>>>>>>> If I am not wrong, documentation says it is not the case >>>>>>>>>>>>>>>> but maybe it is an issue of the method. >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Il giorno mercoledì 28 ottobre 2020 alle 03:37:21 UTC+1 >>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Did you open this in the JavaScript debugger and looked at >>>>>>>>>>>>>>>>> the JS console while doing that? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tuesday, October 27, 2020 at 12:15:15 PM UTC+2 P5music >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is not a regression, I created a test case with a >>>>>>>>>>>>>>>>>> similar layout and it worked with a Google page. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I debugged my app and it turned up being Javascript >>>>>>>>>>>>>>>>>> injections' fault. >>>>>>>>>>>>>>>>>> But it is very strange: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The initial page of the BC is made by: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> webView.setPage("<HTML><BODY >>>>>>>>>>>>>>>>>> style=\"display:flex;flex-direction:column;\" >"+ >>>>>>>>>>>>>>>>>> createLines()+ >>>>>>>>>>>>>>>>>> "</BODY></HTML>",""); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> where it is >>>>>>>>>>>>>>>>>> private String createLines() >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> String result=""; >>>>>>>>>>>>>>>>>> for (int i=0;i<100;i++) >>>>>>>>>>>>>>>>>> result=result+"<BR/><P>TEXT - LINE "+i+"</P>"; >>>>>>>>>>>>>>>>>> return result; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is just to have a long page. At this stage the >>>>>>>>>>>>>>>>>> scrollbar and the mouse wheel work, and the page is >>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Then a list of commands like >>>>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>>>> div=document.createElement('DIV');div.style.position="relative"; >>>>>>>>>>>>>>>>>> div.id="1";document.body.appendChild(div); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> are injected, in a single string. >>>>>>>>>>>>>>>>>> As I can see the BC does not like that commands, even >>>>>>>>>>>>>>>>>> just one of them (I tried just one of them too). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The divs are correctly displayed, also with real content >>>>>>>>>>>>>>>>>> inside them, but the issue is present even with this bare >>>>>>>>>>>>>>>>>> empty div HTML. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> When that command is injected the BC is no more >>>>>>>>>>>>>>>>>> responsive to mouse events. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This method is used: >>>>>>>>>>>>>>>>>> public void executeJS(String command) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> webView.execute(command); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What's wrong with that Javascript injection? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Il giorno martedì 27 ottobre 2020 alle 03:55:28 UTC+1 >>>>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In that case it could be a CEF regression. Can you >>>>>>>>>>>>>>>>>>> isolate a runnable test case that reproduces the problem >>>>>>>>>>>>>>>>>>> and file an issue? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Monday, October 26, 2020 at 1:10:53 PM UTC+2 P5music >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I cannot test on the FX version, I am testing the CEF >>>>>>>>>>>>>>>>>>>> one on the Simulator (no device test available too). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yes I see the vertical scrollbar of the >>>>>>>>>>>>>>>>>>>> BrowserComponent, and it stays also with >>>>>>>>>>>>>>>>>>>> setScrollVisible(false); >>>>>>>>>>>>>>>>>>>> But the BC does not scroll with that, and it does not >>>>>>>>>>>>>>>>>>>> scroll even using the mouse wheel, or dragging over with >>>>>>>>>>>>>>>>>>>> the mouse. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Il giorno lunedì 26 ottobre 2020 alle 04:44:34 UTC+1 >>>>>>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Do you see a scroll bar on the browser component? >>>>>>>>>>>>>>>>>>>>> Did you try this on the device? Did you try it with >>>>>>>>>>>>>>>>>>>>> the FX version of the browser component? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Sunday, October 25, 2020 at 12:28:46 PM UTC+2 >>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So I removed all useless calls to setScrollable kind >>>>>>>>>>>>>>>>>>>>>> of methods. >>>>>>>>>>>>>>>>>>>>>> It is called just on the mainForm and/or its content >>>>>>>>>>>>>>>>>>>>>> pane. >>>>>>>>>>>>>>>>>>>>>> mainForm.setScrollable(false); >>>>>>>>>>>>>>>>>>>>>> OR >>>>>>>>>>>>>>>>>>>>>> mainForm.getContentPane().setScrollableY(false); >>>>>>>>>>>>>>>>>>>>>> is needed to let not scroll the entire user interface. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But the BC is not scrollable. >>>>>>>>>>>>>>>>>>>>>> If I set scrollableY=true for the left container it >>>>>>>>>>>>>>>>>>>>>> does not scroll either. >>>>>>>>>>>>>>>>>>>>>> One of the BC or the left container has to be >>>>>>>>>>>>>>>>>>>>>> scrollable to fulfill my needs. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What further checks can be done? >>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>> Il giorno domenica 25 ottobre 2020 alle 03:14:39 >>>>>>>>>>>>>>>>>>>>>> UTC+1 Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Don't change the scrollability of the browser >>>>>>>>>>>>>>>>>>>>>>> component. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> That option is under zoom and it relates to the >>>>>>>>>>>>>>>>>>>>>>> scrolling of the simulator skin itself. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> You don't need to explicitly call >>>>>>>>>>>>>>>>>>>>>>> setScrollable(false) since that's the default. The only >>>>>>>>>>>>>>>>>>>>>>> thing that's >>>>>>>>>>>>>>>>>>>>>>> scrollable by default if the content pane of the main >>>>>>>>>>>>>>>>>>>>>>> form. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 24, 2020 at 2:09:05 PM UTC+3 >>>>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The CEF BC is used. >>>>>>>>>>>>>>>>>>>>>>>> for the mainform: setScrollable(false) >>>>>>>>>>>>>>>>>>>>>>>> for the BC: setScrollableY(true) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> There is no simulator menu entry "scrollable" to >>>>>>>>>>>>>>>>>>>>>>>> uncheck, and I do not understand why to uncheck it >>>>>>>>>>>>>>>>>>>>>>>> anyway, and what it >>>>>>>>>>>>>>>>>>>>>>>> would refer to? >>>>>>>>>>>>>>>>>>>>>>>> Please can you explain? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I have nested containers and I set them all with >>>>>>>>>>>>>>>>>>>>>>>> setScrollableX(false) and setScrollableY(false). >>>>>>>>>>>>>>>>>>>>>>>> Also the result container of fab binding is set the >>>>>>>>>>>>>>>>>>>>>>>> same. (this result container is added to the form) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> A thing has be noticed. >>>>>>>>>>>>>>>>>>>>>>>> The most deep nested level is a BorderLayout. It >>>>>>>>>>>>>>>>>>>>>>>> has in the north a vertically-short container, then in >>>>>>>>>>>>>>>>>>>>>>>> the center it has >>>>>>>>>>>>>>>>>>>>>>>> the BrowserComponent. >>>>>>>>>>>>>>>>>>>>>>>> When attempting to scroll the BC, just sometimes I >>>>>>>>>>>>>>>>>>>>>>>> see a very tiny movement of the entire BC including >>>>>>>>>>>>>>>>>>>>>>>> the vertical scrollbar, >>>>>>>>>>>>>>>>>>>>>>>> but not the other container in north position. >>>>>>>>>>>>>>>>>>>>>>>> This reminds me that something is scrolling that's >>>>>>>>>>>>>>>>>>>>>>>> surrounding the BC but I cannot understand what. >>>>>>>>>>>>>>>>>>>>>>>> Do you see anything about this? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Il giorno sabato 24 ottobre 2020 alle 07:32:54 >>>>>>>>>>>>>>>>>>>>>>>> UTC+2 Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> How is it set to scrollable? >>>>>>>>>>>>>>>>>>>>>>>>> If you mean in the simulator menu try to uncheck >>>>>>>>>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Are you using CEF or the FX based browser? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Friday, October 23, 2020 at 5:41:50 PM UTC+3 >>>>>>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> My CodenameApp has a main form that splits the >>>>>>>>>>>>>>>>>>>>>>>>>> screen like a master detail layout in landscape >>>>>>>>>>>>>>>>>>>>>>>>>> mode. It is set not >>>>>>>>>>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>>>>>>>>>> A table layout is used with some constraints to >>>>>>>>>>>>>>>>>>>>>>>>>> have this appearance. >>>>>>>>>>>>>>>>>>>>>>>>>> I am testint the app in the simulator. >>>>>>>>>>>>>>>>>>>>>>>>>> In the left part a BrowserComponent is inside a >>>>>>>>>>>>>>>>>>>>>>>>>> container and displays some HTML code. >>>>>>>>>>>>>>>>>>>>>>>>>> I see that the vertical bar appears on the BC >>>>>>>>>>>>>>>>>>>>>>>>>> because the HTML overflows vertically, but cannot be >>>>>>>>>>>>>>>>>>>>>>>>>> moved, it is blocked. >>>>>>>>>>>>>>>>>>>>>>>>>> The BC is not resposive to the mouse wheel too. >>>>>>>>>>>>>>>>>>>>>>>>>> It is set scrollable. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The container is bound to the >>>>>>>>>>>>>>>>>>>>>>>>>> FloatingActionButton that is floating on the >>>>>>>>>>>>>>>>>>>>>>>>>> container itself and the BC. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Do you know any issue that prevents the BC from >>>>>>>>>>>>>>>>>>>>>>>>>> being scrolled? Is it something related to the >>>>>>>>>>>>>>>>>>>>>>>>>> Version 7.0 milestone issues? >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks in advance >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "CodenameOne Discussions" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/codenameone-discussions/d61c5dba-dcb1-439d-8d6c-a147f4ebd300n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/codenameone-discussions/d61c5dba-dcb1-439d-8d6c-a147f4ebd300n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> Steve Hannah >>> Software Developer >>> Codename One >>> http://www.codenameone.com >>> >> -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/a6ce5754-1a96-4ba2-8c99-d2ca7b661243n%40googlegroups.com.
