I tried to follow the steps in the answer of
Directx control in browser plugin
but when I added the solution mentioned in
http://colonelpanic.net/2010/11/firebreath-tips-drawing-on-windows/
FireBreath Tips: Drawing on Windows
"1.Make your plugin object windows specific
change the type of the event source specified in EVENTTYPE_CASE to FB::PluginWindowWin (as well as the type in the handlers) and you will have your object cast in the way you need it."
I got 119 errors, all are in winsock2.h file, which I included in other file,
saying redefinition, different linkage. what to do?
Thanks, Sara
did you add the #include "Win/PluginWindowWin.h"?
another thing that can help that is #include "win_common.h" early in the file. The include order of certain windows headers and winsock matters, so that can cause this issue if they get out of order.
This is a general problem occures when one tries to include windows.h and winsock2.h.
windows.h includes winsock.h itself, therefore, if you include winsock2.h after it, several redefinition conflicts arise.
Solution: include "winsock2.h" first.
Related
I have an embedded project in VisualStudio code which works perfectly fine for the most part. My problem is that somehow _WIN32 is always defined, which leads to wrong includes in some header files.
I guess the problem is an Intellisense issue because the project compiles without any errors (I use the IAR compiler). It's just the error squiggles from Intellisense which display the error.
(For example in one header file it trys to open <windows.h> because of the _WIN32 define, which obviously will fail in an embedded project with an embedded compiler, so Intellisense reports that it can't open the header file)
Now, what i tried so far:
Changing the Intellisense mode but even if I switch it to gcc or clang for ARM, _WIN32 stays defined
Trying to remove the _WIN32 define from code, but it seems that VSCode defines it internally (if that makes any sense ?).
I looked at this thread where they try to answer the question where _WIN32 is defined. But that didn't help me either.
Does anyone have an idea why _WIN32 is defined or where it is defined ? How can i tell VisualStudio code / Intellisense to not define _WIN32 ?
Thanks in advance.
Most likely, the problem is VSCode is using the wrong C++ compiler to gather the predefined macros; that is the likely source of the _WIN32 definition. Use the command Palette (Ctrl+Shift+P) to run "C/C++: Edit Configurations (UI)", then set "Compiler path" to point at your compiler executable (IAR in this case). That should solve the problem because VSCode will then query that compiler to determine the predefined macros.
To confirm the fix, in Command Palette, run "C/C++: Log Diagnostics". The output will show you which compiler VSCode found and what it detected as its built-in include path and preprocessor defines. You should see that _WIN32 is no longer among them. (You might want to run this before changing anything to see the difference.)
Also, you mentioned changing the Intellisense mode. I believe the effect of that switch is related to C++ language dialect issues, especially support for certain bugs in certain compilers. It is unrelated to whether any preprocessor symbols are defined.
(Some of the text in this answer is copied from another answer of mine that more broadly discusses configuring VSCode to emulate a given compiler.)
So I have a library project where I defined a couple of functionblocks and interfaces.
Now I want to use this library in a plc project (in the same twincat solution). So I do the whole save all, rebuild, save and install as a library spiel. If I try to declare a VAR in my MAIN it will result in unknown type errors. I have fiddled around a bit, and when I declare an interface withouth any properties or methods (in the lib) then I it does show up and can be used in the MAIN. But as soon as I add a property or method the class/FB/POU dissapears in the eyes of my MAIN...
I feel like I'm overlooking some option / atribute to help the PLC project to use the lib properly...
What am I missing here?
EDIT:
as you can see in the images, empty blocks are found, adding anything magically makes it dissapear
error
available classes
EDIT 2:
I solved my problem by copying the lib to a new solution. Something in the original project made it be broken. Why it did that is still a mystery...
Try following steps:
clean the solution where you programmed the library.
right click on the project and click check all objects
if this is successfull, install the library again, remove it from the reference section and re-add it.
Then clean again and build all.
I have encountered a situation where xcode stops auto-completing and if you try to write a variable that already been defined xcode says << error type>>.
Here is my error:
I have started to see same errors after Xcode 6.1 and iOS 8.1 update. I have found that if you delete ModuleCache file at /Users/username/Library/Developer/Xcode/DerivedData/ModuleCache path, it fixes the error temporarily. And you don't have to close Xcode or the project while doing that. After deleting the file, just wait for Xcode a little to index the project files again. After that, the problem mostly resolves for some time.
As it doesn't solve the problem permanently, you should avoid writing codes causing this according to other answers till Apple solves this.
Often this indicates that your code doesn't currently compile. Swift often has trouble computing types on code that itself isn't correct. In some cases it's a bug in the compiler. Use of AnyObject can be particularly confusing to the compiler, and should be avoided as much as possible. In this case, AnyObject is required, but you should try to get it converted to a specific type quickly. Don't return [AnyType] for instance if you can possibly help it.
But the short answer is that the Swift compiler is still evolving, and it can't always work out types in complex situations, particularly on partial or (currently) incorrect code.
Note that you're using var for a lot of things that should be let. Unless you actually need to modify the variable, you should prefer let. It helps you prevent many kinds of bugs, and can be easier on the compiler to deal with (since the variable has fewer ways it can change).
<<error type>> can result from the Swift compiler not finding the header file.
Same module:
Do you have some sort of folder structure that your source code is in? If so, try setting Scan All Source Files for Includes to YES.
This will make Xcode look through all of those folders when trying to find the Header file.
Embedded Projects, multiple modules etc:
1. Check the Search Paths
Have a look where the file in which your type is defined is stored.
In your Build Settings make sure that this location is included in the Search Paths.
If it is part of the User Header Search Paths, make sure, that Always Search User Paths is turned on.
2. Check dependencies
Have a look at superclasses etc of your type. Are they included in the Search Path as well?
Found out that the error goes away and autocomplete works again if i initialised the variable like this:
var name: String = "my name"
instead of :
var name = "my name" as String
Firstly, try CMD-SHIFT-K followed CMD-R to clean and then run the build.
If that doesn't work, close XCode, delete derived data, and reopen XCode.
I faced the same issue recently. I tried running the whole project on an emulator, it resolved all the <<error type>>
I switched my build destination from Any iOS Device (arm64) to one of the available iOS Simulators, and that fixed the issue for me.
For me, simply restarting my computer resolved this issue.
Is there a way to make Eclipse keep used but unresolved imports?
I'm using Eclipse's save actions to remove unused imports. Unfortunately it also removes imports that are used, but not unresolved.
In the example below, eclipse will remove GeneratedClass, if I save MyClass before generating the GeneratedClass. When I late generate the code, MyClass will be missing the import.
import a.b.GeneratedClass;
public class MyClass extend GeneratedClass {}
Thanks to Bananeweizen and Krispy for their contributions, but so far it seems that the answer to this question is No.
The most efficient work around for me, is just to hit ctrl+z every time I save a file with unresolved imports.
I have submitted a bug to Eclipse's bugtracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=395538
This Eclipse bug tracks this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=357795
Don't use the save macros and instead hit Ctrl-Shift-O which will give you more explicit control over when the imports should be tidied up.
You can disable the clean up action and instead remove the unwanted imports manually one by one using Ctrl1 to invoke the quick fix for that.
Nevertheless you are just trying to hide the real problem. The real problem is that your generated code is not generated at the right time. You should fix that. If you don't know how to automatically involve actions in Eclipse during every project build, please look at this example (which automatically creates a jar file with a custom script during every build). You can have those builders applied to the project in any order that you want, so you can always have your code generation invoked automatically before the Java compiler, on saving your Java files.
This thread is very useful for finding out which files in Netbeans should go into source countrol, but it doesn't cover all files.
In particular I'm wondering whether the following files should go into source control. Here are my assumptions/guesses:
nb-configuration.xml - easiest - the file itself in the comment says it should go into source control.
nbactions.xml - from what I see this file stores information typical to running the application. I.e. JVM arguments etc. So I suppose it is a question of taste - if you want other developers to have a "suggested" Run configuration - include it. Otherwise - don't. Correct?
catalog.xml - not sure what this does (I GUESS it's used by the editor to find out xml schemas and such to enable syntax coloring, but it's just a guess). Anyway - I see that this file has system-specific information (path) - so it shouldn't go into source control.
Can anyone confirm the above?
Thanks,
Piotr
I never put my IDE configuration files in the repository, for several reasons:
other colleagues may want to use theirs;
other colleagues may want to use other IDEs (such as Eclipse) and seeing those files (or even have to exclude them from the checkout) could be annoying for them;
some of these files are generally not related to a single project, others automatically generated, so no need to store them in the source code of every project.
In order to exclude them, our first solution was the .svnignore, but it was still logically wrong to modify some shared content for the specific needs of a single user, so we decided to be more strict:
in my ~/.subversion/config I have:
[miscellany]
global-ignores = nbactions.xml nbproject
Hope this helps,
Marcello
In my Maven based projects I put nbactions.xml into source control. Just make sure to change absolute paths to relative ones.
I put nbactions.xml into source control BUT there is a caveat: it's internal format can change so if your developers, for any reason, use different versions of NetBeans you could have to remove it because sharing it becomes nasty.
Recently I upgraded from NetBeans 7.3.1 to 7.4 and the "Run" action was giving a strange error message. I solved the problem by deleting and regenerating nbactions.xml: the old one had a custom Maven goal for the "Run" and "Debug" actions; it was org.codehaus.mevenide:netbeans-deploy-plugin:1.2.4:deploy it was not visible in the IDE v7.3.1 (perhaps it has been generated by an even older version for internal usage) and was generating a class not found for org.openide.util.Lookup in v7.4. I'm documenting the problem here because I found the solution by myself after an unsuccessful search on the Net. I hope this can help someone else.