I am trying White for the first time. I tried to run a sample test to get a window of notepad, it doesnt seem to work. Here is what I did:
//Launch the app
Application app = Application.Launch("notepad.exe");
//Get the main window after launching the app
Window win = app.GetWindow("Untitled - Notepad");
This last line throws an error as type initializer exception. When I go into the source code for White, it fails at finding the window.
When I used GetWindows() and try to get first window, it works fine.
But the same error is thrown for the child objects as well.
I have Win7, 32 bit. By build configuration is Debug|x86. I also tried the same code on Win XP, 32 bit and it worked well.
Can anyone please tell me how do I go about this.
I think I found the solution. When I tried running same code on a Win 7, 64 bit machine, it seemed to work perfectly alright.
I tried using the dependency walker and found that there is some issue with the dlls on my machine. Though I dont think I can get my system fixed just for that, I guess it might help others if they are facing this issue.
Related
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
I'm having some trouble with WebExtensions in Firefox. I've got some code to track downloads, and it's working in Chrome, but not in FF.
I've boiled the code down to the minimal surface that works in Chrome but not FF:
function handleChanged(delta) {
console.log(delta);
}
chrome.downloads.onChanged.addListener(handleChanged);
Whether I use chrome.* or browser.*, the behavior remains the same: it doesn't work. I've tried executing this line:
console.log(chrome.downloads.onChanged.hasListener(handleChanged));
After adding the listener, and it does log a value of true. Oddly enough, adding an onCreated listener works just fine:
function handleCreated(delta) {
console.log(delta);
}
chrome.downloads.onCreated.addListener(handleCreated);
This yields the expected object dump in the console when a download is started. Unless I'm missing something extremely obvious, I'm inclined to think this is a bug. It is not mentioned to the incompatibilities list, and it is documented by Mozilla. The thing is, I don't see anybody else asking this question online, so I'm inclined to think a bug is unlikely and I'm messing something up.
If it helps, I'm running Firefox 51.0.1 (32-bit) on Windows 7 Enterprise x64 inside of VMWare Workstation on a Windows 7 Enterprise x64 host. I'm loading the extension using the "Load Temporary Add-on" button. It's not a problem with the core manifest or add-on itself, because three other types of listeners are working just fine. The script is running as a background script.
I appreciate any guidance. Thanks!
Im trying to make apps and always when I set the elements in the xib, it looks fine, then I open the simulator running 6.0 and some elements appear lower than they should, or some are a bit bigger than in the xib.
Why is this? I unchecked the "Use Autolayout" and still it appears in a different way.
Any idea?
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