I just created a simple MFC dialog based application in VS2005. Whenever I am trying to add variable to an edit control I am getting this error.
I am new in MFC. Please help me fix this :(
Using: C++98 with VS2005
Did you add any variable(control/value) to any of your control and fortunately you deleted it?
If so, you have to remove the ID for control in resources.h and app.rc and also variable initialized in .h files and used in your cpp files.
It may also cause this problem. But im not sure.
Related
I had a working project in Android-Studio, including Databinding. That eleminates some possible sources of error. ;-)
Then I decided to get my feet wet with Kotlin and began to migrate some classes from Java to Kotlin.
Unfortunately I also klicked to update Android-Studio to 3.4 in the middle of this process. So now I have many moving parts ...
Now after some editing, when I try to compile my app, the databinding-classes are not generated any more. Usually this is a problem of missing getters or setters or something like this. But currently I have no compiler errors that indicate such problems. Only all the references to my BR. class are red as this class is not generated.
In the layout-files the getters and setters from the data-variable are not shown - so there is a problem already there.
The build-log tells me to check the log for details, but I can not find any log with error-messages that could lead to a solution.
Android-Studio 3.4, mixed Java/Kotlin sourcecode
Besides those missing BR class, I have no other compilation errors at the moment.
I checked the raw gradle output and also tried to run those steps with the more verbose output - no luck.
Maybe this is related:
- I also have problems to edit my existing layouts with constraint-views. Somehow the constraints are read-only.
After some fiddeling around I managed to get one layout back to read-write mode. Not shure what I did to accomplish this ...
- Also I have the problem that Android-Studio "remembers" the last project and mixes the configurations from the last project with that of the current one. To fix this I have to delete the .idea folder in the project ... After that I can work with my project until I change to another or open a second one in parallel ... :-/
In order to get logs I also changed to generate the binding-classes by the compiler instead on the fly by Android-Studio - no luck.
As this is an installation with some history, I also tried to delete the configuration-files from Android-Studio - also no luck.
Clean- and Rebuild Project, Restart Android-Studio, Invalidate Caches ... all that tried without success.
Currently I am out of ideas where to look. Maybe somebody out there has a tip for me?
if you use imports in xml like
<import type="java.lang.Integer"/>
you have to delete it because android studio is imported automatically.
ref :
Just as in managed code, java.lang.* is imported automatically.
Finally I found the source of my problems!
After many attempts to find an error in my code or maybe in Android-Studio (also downgraded to 3.3 and tried the current 3.5 canary version) I decided to strip down the code to the max.
So I created a new project. In that project I created 2 observable classes and copied the minimal code from https://developer.android.com/topic/libraries/data-binding/observability#observable_objects.
I created one class in java and one class in Kotlin (with an index-Number at the properties so that I could see which properties are generated in the BR class).
Only the properties from the Java-class were generated in the BR class, those from the Kotlin class were missing. No error messages besides the missing BR-properties were generated. :-(
With this information I started a new research and finally found, that for Kotlin currently the apply plugin: 'kotlin-kapt' was missing in the project build.gradle file.
Once I added this, also the properties from the Kotlin class were added to the BR class.
Some (older) articles also add kapt "com.android.databinding:compiler:x.x.x" to the dependencies, but with the latest compiler I got null-pointer exceptions. Seems that this component is already referenced somewhere else, because it is not necessary (any more).
I also added this to my other project and now those BR-properties are also present there. So I am confident to have found the answer to my question and can now focus on bugfixing my app.
I have a question regarding Dependency Properties in WPF.
I am working on a project which uses controls from another package. I modified one of the controls by adding new dependency properties to it. However, when I try to access them in xaml that is in my project, I get error stating that there's no such property in my control. At the same time when I set the values of those properties in style for this control in a file that is located in the same package as the control, everything works. Also, the old dependency properties work fine.
I'm not sure what code to include to illustrate this, please give a hint.
Could anybody at least hint what is going on?
Thank you in advance.
The problem was that I didn't include in Build-Events of my first solution where the controls reside the path where to copy the respective dll so that the second solution could detect the changes.
I'm very new to SharePoint development, and I'm just trying to add an XML file to a Feature to reference the XML file content in the feature Event Receiver.
It seems that the general recommendation is to use do so like in this SO question:
How to retrieve data from an XML file in a Sharepoint 2010 Feature Event Receiver?
However, my code does not compile when I reference the RootDirectory property. The error I see is below
'Microsoft.SharePoint.Administration.SPFeatureDefinition' does not contain a definition for 'RootDirectory' and no extension method 'RootDirectory' accepting a first argument of type 'Microsoft.SharePoint.Administration.SPFeatureDefinition' could be found (are you missing a using directive or an assembly reference?
Now, the weird part is that while debugging, I am able to evaluate the RootDirectory property correctly in the Quick Debug window.
Am I missing something obvious? Like I said, I'm completely new to SharePoint.
My feature is scoped to the Web level, and I do have a reference to Microsoft.Sharepoint.Administration in my using statements.
Any help is greatly appreciated, thanks.
It was indeed something very basic.
The solution/project was set as Sandboxed. Just going to the properties of the project (not the property pages but hitting F4 while the project is selected on Solution Explorer) and setting Sandboxed to false will let you compile when you're accessing the RootDirectory solution in code.
Also, a few other properties/method not show up when the solution is Sandboxed instead of marked as a Farm solution.
Environment: VS2008, C++ ATL COM, 64Bit, Windows 7
I'm trying to remove a method from an older COM interface. I modify the *.idl, modify the associated *.h and *.cpp implementation files and also remove it from the main project's .h file. I can search the whole project for the old method name - does not show and it compiles/links fine. However, if I then use the Object Browser to look at the compiled DLL - the dang method is still there! If I 'reference' the DLL in a .NET project - shows the method. If the .NET code attempts to use the method - it gets a memory exception (which makes sense). I can't for the life of me figure out how to modify the IDL, remove the method code and have the resulting compiled DLL be correct.
Where the heck is the method lurking and is there a different way to remove a method from an existing ATL generated COM interface? I'm stumped! Thanks!
Did you unregister the old DLL module and registered the new one? Sounds like your registry may have an inconsistent entry.
Also make sure there are no pre-compiled headers etc laying around so that when you compiler you are sure it hasn't included some old copy.
probably best is to delete the complete build directory (debug/release) before compiling just in case you missed deleting some old files.
check also the path where the .dll is loaded, you can see that in the object browser, compare that with the registry entry. maybe you did a 32bit version before?
I'm using VS2010 and in my solution one of my C++/CLI projects references the other. But it can only link correctly when the project being referenced is compiled as a Static Lib.
I read all over that in managed .NET languages, .EXEs, libs and .dlls are the same thing, with a single flag or something like that as difference. Being like that, I can't figure out why I have all these linking errors, since it shouldn't matter how I compile my project.
Well, probably I'm assuming something wrong. If so, how can I reference a .exe project in an other .exe project so I can use the same classes and methods without having to recompile it.
Thanks in advance,
Theo
While referencing an EXE project and loading it at runtime as though it were a DLL is okay for pure managed code, that is not going to work out well for a C++/CLI project. The CRT won't be initialized correctly, there is no DllMain() entry point that will run.
You'll need to create a DLL, use the CLR Class Library project template.
What ever compile or link errors you'll get after that might be secondary. Make sure you quote them in your next question, error messages were designed to tell you what is wrong.
Right click on your project and choose "Add reference..." in the menu.
PS: can you show the linker error messages?