As the title says, this post is meant to highlight two bugs that weren't there before last CN1 .jar updates:
Launching a codenameone app in debug mode fails
New or modified rounded rectangle border defined through the theme file are forced in top only mode
Launching a codenameone app in debug mode fails
I'll start with the 1st one as it is the most disturbing.
On Eclipse, launching the app in debug mode results in the following error (that I wasn't getting last week):
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:735]
Initially, I thought that the socket was failing to initialize as the port was being used. That is also what you would mostly find on internet. So I checked the command line used to find out which port the socket was trying to connect to so that I can check if that port was available:
C:\Program Files\Java\jdk-13.0.1\bin\javaw.exe -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:54499 "-javaagent:C:\Users\Roman\eclipse\jee-2019-09\eclipse\configuration\org.eclipse.osgi\1095\0\.cp\lib\javaagent-shaded.jar" -Dfile.encoding=UTF-8 -classpath "D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\JavaSE.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\bin;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\CLDC11.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\CodenameOne.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\impl\cls;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\impl\stubs;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\native\internal_tmp" com.codename1.impl.javase.Simulator be.selisys.rdf.firstonpersonalpc.FirstOnPersonalPC
We can see that it is attempting to use port 54499 (in fact, in gets incremented by 1 at each command line call). Now the funny thing is that this port (and the many following ones) is (are) effectively free!
I tried things such as rebooting Eclipse, my computer, check the dt_socket.dll, ... but none of that helped. After hours thought, I noticed the debug mode was working on other applications, but not on CodenameOne ones.
I then moved to another computer:
Turned off the internet, ran the debugger on a CN1 app ==> Works fine
Turned the internet back on, send a built to get the jars updated, ran the debugger again ==> same error as above :(
Since I now know that it is obviously related to CN1 jars last update. Have you got any idea on how to solve that? How much time should we expect for a solution to come up? Any idea of a workaround? Maybe I can use the old jars, if there is a place to find them.
New or modified rounded rectangle border defined through the theme file are forced in top only mode
That is less important, but still annoying: basically, we can't use rounded rectangle borders using theme unless we have set them before the recent updates (I have no clue on since when the bug exists except that it is no older than 1 month). If you create/edit a rounded rectangle border, I will automatically be set to top only mode upon save. The current workaround I am using is creating a hard coded RoundRectBorder.
As above, the bug appears on any computer which get its jars updated.
Hope pointing these out will help them getting resolved earlier. :)
Cheers
Related
After a lot work invested in getting CefNet to work on Windows, I wanted to port my NET 7 app to Linux (Ubuntu). To my understanding CefNet is the only implementation that will work on Linux.
I got to a point where I am getting the exception below. Spying on source code using DotPeek leaves me under the impression that CefNet won't work in "headless" mode but will require "X server". Not sure why this would be necessary for off-screen rendering.
Any insight is appreciated.
Unhandled exception. System.InvalidOperationException: Operation is not valid due to the current state of the object.
at CefNet.CefScreenInfo.GetPrimaryScreenInfo()
at CefNet.Internal.WebViewGlue.GetScreenInfo(CefBrowser browser, CefScreenInfo& screenInfo)
at CefNet.Internal.CefRenderHandlerGlue.GetScreenInfo(CefBrowser browser, CefScreenInfo& screenInfo)
at CefNet.CefRenderHandler.GetScreenInfoImpl(cef_render_handler_t* self, cef_browser_t* browser, cef_screen_info_t* screen_info)
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
I am trying to pull data from a Salesforce API account using Pentaho/Kettle Spoon. I am able to establish a connection on Pentaho with this account. I am also able to get fields from specific modules. However, when I try and "Preview rows" (even with a small number of rows), the "Operation in Progress" window comes up and never completes the task. When I try and cancel the job, Pentaho hangs and I have to force quit it.
I am running Fedora 21. Any input is greatly appreciated.
Thanks!
This works for me:
Since upgrading to Fedora 22 Spoon (the client tool of PDI) was not working properly anymore. Although I could start Spoon properly and create transformations etc, once I wanted to execute a transformation or sometimes even when trying to open settings, nothing was working and the terminal window showed several (SWT:20352): GLib-CRITICAL error messages. In a nutshell, Spoon was rendered useless.
Here is how to solve this:
Go to the Eclipse Download Page and download the latest 64bit verion of Eclipse IDE for Java EE Developers. Note: There is a separate download area for SWT; however, for Linux there is no 64 bit version available. The only way to get one is to build it yourself. So I just went the easier way and downloaded Eclipse instead.
Unzip the file and search for swt. A search result will show a few files, but the ones interesting for us are (your version number might be different): org.eclipse.swt_3.103.2.v20150203-1313.jar and org.eclipse.swt.gtk.linux.x86_64_3.103.2.v20150203-1351.jar.
Copy the first one of these files into <PDI_HOME>/libswt/linux/x86 and the second into <PDI_HOME>/libswt/linux/x86_64.
oth folders still have the original jar files in them. Rename them to swt-jar-old (Note: no extension, so that they are not picked up).
Start Spoon. There will be a few error messages shown, but so far Spoon is working way better for me than before.
FONT: http://diethardsteiner.github.io/pdi/2015/06/07/Fixing-PDI-GLib-CRITICAL.html
i'm running Ubuntu 14.04, i5,6gb RAM, got same trouble..
when i check, the load in proccessor is 100%, evertime i try showing the content or other thing in pentaho, the Operation in progress is show up, and never end..
How to solve, check your access to file/connection in your database,unrecognize file,field,etc. after this resolve, my proccessor run normal, and i could run / execute the transformation.
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.
I've got a strange problem I haven't seen before. I can open an OpenFileDialog in Windows 7 without any problems. However, when I try my app on Windows XP, calling OpenFileDialog.ShowDialog() immediately crashes the application. It just vanishes! When running from the debugger, I don't get any unhandled exceptions. If I wrap the code in a try/catch block, nothing gets caught. I have also checked all thrown exceptions in Debug -> Exceptions, but nothing pops up. I'll try some of the other suggestions in the answers below and will report back.
Does anyone know how to resolve this problem? I found a post about something similar, but it was the opposite problem. I'll try tweaking the desktop settings to see if it's related to that, but I am dubious.
EDIT -- as a sanity check, I wrote a test WPF application that displays an OpenFileDialog directly via the main window as well as another Window that can be displayed by the main window. It totally works fine under Windows XP. So now I'm really confused. I have verified that I'm not doing something stupid like trying to display the dialog from a worker thread. The OpenFileDialog displays briefly, then disappears along with the application.
EDIT -- I'm going to try to reproduce this problem on another XP computer. For now, I'll try Windows XP mode and we'll see what happens.
I got a similar error when a DLL crashes when I open a OpenFileDialog. It turned out that OpenFileDialog changed the working directory so my dll tried to write to a relative file that did not exist.
Do you see any "First Chance" exceptions in the Output? Any entries in the event log? Does the default path you're using exist on the XP machine?
Try adding a handler to the App Domain's UnhandledException
Does the same happen when you use a brand new, stock FileOpenDialog without any tweaks? What about from a brand new app which does nothing but show a file open dialog?
See Galet's post
I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
1.Switch to release mode
2.Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3.Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)
link|edit|flag edited Apr 12 '09 at 22:32
answered Apr 10 '09 at 19:01
galets
1,2201924