We've recently upgrade our Application to run under Java 11 (used to be Java 8).
There is one panel on our apps main screen that Files can be dropped onto.
This works fine on Windows but not on OSX. (used to work under Java 8, failed after switching to Java 11).
A file can be dragged from another Java application that supports it, but NOT from Finder.
The TransferHandler.canImport() method is never called.
The DropTarget.dragOver() method IS called, but the drop() method is never called. I can't trace into runtime library methods, as it doesn't have line number information.
I've found that I CAN drag files from Finder to another Java app, or to a JDialog in our main app.
It only fails if the JTable is in a panel in our main application window. So our app must be doing something odd to cause it to fail.
The problem is finding out WHY it fails, only on OSX. This is a LARGE application, and the main window is quite complex. Posting a Self Contained source example is impossible - especially since the simple case works.
What I could REALLY use is a Java 11 Runtime library that has line number information so I can step into it. Yes, I have the full source that came with the Java 11 JDK. (Adopt OpenJDK) I've been unable to get it to compile under Eclipse.
Any suggestions on what our app could be doing to cause this to fail? Or where I can find a Debug Java 11 runtime library?
Sure would have been nice to have a Debug runtime library.
The issue is that on the calls to DropTarget.dragEnter() and .dragOver(), the data in the Transferable and the getCurrentDataFlavors() is invalid on OSX.
getCurrentDataFlavors() will return a list of ALL data flavors - none of which will have any transferData. (this means that the data is also invalid in all the calls to TransferHandler.canImport() as well.)
The ONLY time the data is valid is in the TransferHandler.importData() call.
Our code was checking to see that the user was dragging a file of the correct type in the canImport() call. Since all the data is now invalid (OSX, Java 11) that call was throwing an NPE (since the getCurrentDataFlavors() included our desired flavor, but the getTransferData(flavor) return null. Note that this worked correctly with Java 8.
Combine that with the Runtime drag handling code that silently ignores exceptions, well, not quite ignores them, it disables all further Drop operations on that target when one happens. That makes it really difficult to track down what is happening.
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
I'm adapting an air extension for PC to the Mac. Successfully creating a project
which "ought to" work, but instead I get
Error #3500: The extension context does not have a method named
The packaged ANE is being loaded successfully, but no calls work. I suspect
that the initializer is not being called (and nothing is complaining about it).
My evidence being that I removed the initializer and finalizer from the C project
and the behavior did not change.
Any suggestions?
Versions: Xcode 3, Air-15, Flex 4.13, Flash Builder 4.7
Edit: more information; I discovered that exporting the application as a release build/signed native installer, then installing and running the application, it works
(well, still needs debugging, but the extension methods are being reached). So the
question simplifies to "what is wrong with the flash builder environment"
It is apparently impossible to use flash builder in conjunction with air native extensions on OSX.
Creating the extension context works without complaint, but calling any of the functions provided
results in "error #3500: The extension context does not have a method named ..."
It cost me a lot of time (and therefore my company's money) to discover that the ANE is actually fine, and can be
invoked outside of flash builder, by an appropriate command line, or by packaging a release executable.
This total package of behavior is very unsatisfactory, and has been known about for at least two years.
Even with the workaround (release packaging, or invoking using a command line) the workflow is
severely degraded.
--
for reference, the most helpful explanation of the workaround is at this URL
http://riawanderer.com/2012/03/27/working-with-air-native-extensions-on-the-mac/ note the date of this post!
then search for the panel that follows the text
"Now that simple demo code is ready, let’s run and see what does it do. When you run the app you should see below error indicating that Flex Builder Bug exists :)."
I built a (customized) 1.8 HotSpot VM in Netbeans 7.2 using GDB 7.4 which works for executing Java programs. I want to debug a SIGSEGV that the program produces by calling a native function called by JNI that corrupts an object header.
However, I have some problems debugging the HotSpot VM: I have several breakpoints before the call to the main function in java.c. Sometimes, they trigger and sometimes the main function executes without all the breakpoints halting before. The most far I can get is
/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
After that, a step-in runs through the whole Java program, eventually triggering the SIGSEGV. The call is leading to the JNI API so I included the "hotspot/src/share/vm/prims" directory to the source dirs in the debug section. However, I could not see any effect. Does anybody have an idea how I can step into the C++ method calling the Java main method?
When the SIGSEGV causes the Netbeans debug view to stop, the call stack shows the expected call stack. However, instead of the C++ code it just shows assembler code while displaying the names of the C++ classes. The initial caller is "?? ()". Is there some way to see the C++ code or do I have to manually map the assembler code to the C++ code? I read a great article by Volker Simonis where he describes that such unknown frames relate to generated code. However, I'm still puzzled that the consecutive caller frames show class and method names. Is it a problem with source lookup or simply relates to the first unknown frame?
Did you compile hotspot in debug mode, i. e. make all_debug? If hotspot is optimised than code may be run in different order than it's in source file, and some symbols can be stripped out, preventing debugger to give you meaningful info, or setting a breakpoint.
I'm curious if anybody could help with a problem I'm having. I just downloaded and installed the SDL 2 framework, along with the example programs that come with it, from Mercurial (http://www.libsdl.org/hg.php) onto OSX Mavericks (10.9).
I am attempting to run the example native cocoa code in Xcode 5.1.1, which includes the files testnative.h, testnative.c, and testnativecocoa.m that come from the tests folder in the Mercurial download.
I am successfully able to build the program, but as soon as it hits the function SDL_CreateWindowFrom(native_window), the program crashes and highlights the following line of a file called SDL_cocoakeyboard.m:
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow; Thread 1:EXC_BAD_ACCESS (code=1, address=0x8)
The only thing I did with the original files was change the include headers from SDL.h and SDL_syswm.h to SDL2/SDL.h and SDL2/SDL_syswm.h in testnative.h. I've included both the cocoa and SDL2 frameworks in the program, and I turned off automatic reference counting, which was necessary to get the example code running.
I have no idea where else I could be going wrong, since the code before the aforementioned line looks and runs fine (it's able to create the cocoa window before it crashes).
Any insight on this issue would be great. Thanks in advance!
I was wrong in the comment, driverdata is null (never initialized), some code like SDL_cocoawindow.m:SetupWindowData would be required, but SetupWindowData is static (not global) and adding a minimal initialization would require SDL_cocoawindow.h(but isn't public).
So, my guess (maybe I'm wrong) this testnative isn't working, at least not with current SDL2 (the wrong #include should have been a sign) but a fast look into SDL2 shown there's enough cocoa code to hope there are other ways to get a native window working.
A good start How to set up a SDL 2 project for OS X in Xcode 4
I have a project which has several components loaded by a single preloader swf.
The preloader swf is strictly AS3 (No flex) and uses Loaders to load two different swfs which both use the flex library (Statically compiled, not rsl).
When I compile all three under linux and run the resulting preloader, one of the swfs fails to load properly, and the exception below (at the bottom of this post) is thrown.
If I compile the same component using the same ant task in windows, the component loads just fine without error. The windows file is also 683 bytes smaller.
This is true using the flex SDK 3.2.0 and 3.3.0 under linux and windows.
Have you seen this type of behavior? Can you offer any suggestions for why it might be happening, or how to determine what is wrong?
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::FocusManager/activate()
at mx.managers::SystemManager/activateForm()
at mx.managers::SystemManager/activate()
at mx.core::Application/initManagers()
at mx.core::Application/initialize()
at OC_Footer/initialize()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::childAdded()
at mx.managers::SystemManager/initializeTopLevelWindow()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::docFrameHandler()
at mx.managers::SystemManager/docFrameListener()
So wait, are you using different version of the SDK in each platform? That would certainly account for some differences (at the very least in the size of the swf...)
IIUC you get this error when you're loading the page in the browser, right? It's hard to tell from just the stack trace what's wrong, but I can tell you that I used to get a similar error on Windows and it had to do with keyboard events (e.g. using the tab key to move between elements when popups are visible, and similar stuff). Sorry I can't offer a more accurate diagnosis.
I'm not sure I've solved the real problem (Why the compilation was different under different OS's), but I have found that the newer version of the flex SDK does not exhibit the same issues.
I created a bug for the issue here:
https://bugs.adobe.com/jira/browse/SDK-20147
The short of it is, build 3958 (The one default with flexbuilder at the time that I created the bug -- This may still be true) appears to have a number of minor bugs. Upgrading the flex SDK to build 4852 alleviates the symptoms, and I can build projects successfully in a number of environments.