I am currently learning Kotlin through a Udemy course for Android Development and I cannot proceed with the course unless I fix all the problems I'm having. One of these problems is Failed To Instantiate one or more classes
It gives a detailed description saying:
The following classes could not be instantiated:
- android.support.v7.widget.ActionBarContainer (Open Class, Show Exception, Clear Cache)
- android.support.v7.widget.ActionBarContextView (Open Class, Show Exception, Clear Cache)
- android.support.v7.app.WindowDecorActionBar (Open Class, Show Exception, Clear Cache)
Tip: Use View.isInEditMode() in your custom views to skip code or show sample data when shown in the IDE. If this is an unexpected error you can also try to build the project, then manually refresh the layout. Exception Details java.lang.ClassNotFoundException: android.view.View$OnUnhandledKeyEventListener
I am new to Kotlin and Android Studio so there are a lot of things that I don't understand, I tried doing something in the Gradle but it just closed or crashed(I'm not really sure)Android Studio and I had to reopen it.
Make sure that you have this line in gradle (Module:app)
implementation 'com.android.support:appcompat-v7:27.1.1' or later
then
Build/Clean Project
Build/Rebuild Project
and if necessary
File/Invalidate Caches / Restart
Related
I'm not sure if I'm missing something here, but it doesn't appear to be possible to debug exceptions in Jetbrains Rider.
I have an incredibly simple piece of code that throws an exception (invalid file name) and there is no way I can find to
a) stop on the exception line in my code raising the exception, and
b) view the value of any variables in my source code that may have contributed to the exception.
I've recorded a sample video here that shows the debug attempt, and why it seems illogically impossible.
Has anyone found a way of debugging this stuff? Is Rider actually broken?
Sample video showing (attempted) debug session
For anyone experiencing the same situation, enable "Any Exception" and disable "Only break on exceptions thrown from user code" in Breakpoint Options.
You can also (as #mu88 mentions) disable debugging of external sources, but that simply reduces the clutter in stack frames.
I'm trying to build an Xcode plugin using this template. As a matter of fact the template works perfectly, but the problem is that something strange happened and it stopped loading the plugin. After 3 hours of trial & error, I pinpointed the problem but I cannot get my head around this...
I have a class called MHStatement and when I build without including this class, the plugin works fine and appears in the Xcode menu bar as expected.
However, when I include the MHStatement.h and MHStatement.m files in the project and then build, the plugin fails to load.
Now the fun part is that if I rename MHStatement to Statement and build it still doesn't work.
But if I make a new interface & implementation Statement overwriting the above Statement files it works again.
Moreover, creating new classes named _MHStatement, __MHStatement, MXStatement, MBStatment, MHFatment also make it fail, but XXStatement, DDStatement, XHStatement is OK.
But when I create a class XXStatement, and refactor->rename it to MHStatement and build,
the plugin loads normally.
This is obviously some weird runtime or linking error, but I don't know how to even start looking for what exactly is happening.
I am not sure if this is reproducible by any means, so I would just kindly ask for any advice that might come to your minds.
Cheers!
EDIT
I tried creating a new class MHStatement and adding it to BBUncustify plugin. Building the plugin like this also prevents it to load, but now I'm getting this warning
objc[6278]: Class MHStatement is implemented in both /Users/marko/Library/Application Support/Developer/Shared/Xcode/Plug-ins/UncrustifyPlugin.xcplugin/Contents/MacOS/UncrustifyPlugin and /Users/marko/Library/Application Support/Developer/Shared/Xcode/Plug-ins/PluginTest3.xcplugin/Contents/MacOS/PluginTest3. One of the two will be used. Which one is undefined.
with tail -f /var/log/system.log
I ended up creating a new project from scratch, and now have 3 separate targets, a framework for the code base that actually does all the work, test cases for the framework, and a simple one class plugin target, which works fine with that setup.
I hope some day someone will be able to answer what exactly was happening, and Apple will become kinder to Xcode modding community.
I used to develop a habit in Eclipse to use Error List to check errors and warnings. Is there something like that in IntelliJ IDEA? I don't see it.
Eclipse incrementally builds the whole project all the time and finds all compilation errors even in classes you haven't touched/opened at all.
IntelliJ is not building your whole code base upon every change so there is no such view. The closest you can get is Messages view (available under Alt + 0) but it only shows compilation errors discovered when a file with errors was physically opened (or when the whole project was built).
UPDATE
IntelliJ IDEA 12 will most likely have incremental compilation feature:
Currently supported: incremental compilation of Java, Groovy, resource copying, UI Designer forms, Artifacts, Android, annotation processing, not-null instrumentation
It's also possible to look at tiny red stripes on the scrollbar to find where the errors in a file are located (they couldn't make it less convenient to use :/)
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I have a windows form application in which I'm attempting to utilize a plugin (class library). In the code I have it load the assembly from a dll file, which means I have not been able to debug. Furthermore I have not found out how to compile the library so I've had to use the debuged dll version for testing. I've run into a bug in which I create a new object and send that data through an interface to the plugin in an attempt to retrieve a blank slate group box from the plugin. However instead of reading the parameter as a new object i managed to step through the code once (don't ask me how, I don't know and I haven't been able to repeat it) and it appeared that the code was registering the parameter as "nothing" thus why I received a null reference error in the main program.
Is there a better way to debug this mechanism and find out where the problem is? Any ideas on what the problem could be. As I read over this is seems somewhat vague and I'm not sure how to describe it, but I'm willing to host a connect now meeting if anyone is willing to look at what is going on and I'm not making myself understood very well.
I'm not sure if I follow exactly what you're doing but I usually find that the best way to debug a class library is by in the solution for the class library I add a new project, either a WinForms one or a Console one, I then set this new project as the start up project and add a reference to the Class Library project (via the Project tab in the Add Reference dialog).
You'll then be able to call the methods in the class library from the other project and you can put breakpoints anywhere to see what's really going on easily.
Ok, so the problem was that any time you edit the class library you have to compile (and the only way I know how is debugging, I can't find a compile button and the publish button doesn't work and building doesn't appear to make a dll). But anyways you have to compile, transfer the file so you are reading the most recent one. If you edit the code during runtime it does NOT update the dll in use...which was my problem.