I have a little problem with the creation of a user control.
Though I have made a control I want to use in another control.
As soon as I want to add the reference (would like to use it as compiled OCX) in the Component's list, the message "Wechselseitiger Verweis zwischen Projekten nicht zulässig" which means something like "Circular referencing between projects is not allowed"
Strange is that the control I want to use does not have any type of reference to the first project.
I've checked this using dependency walker which is shipped as a tool with Visual Studio, but it says as well that there's no reference to the other control. I've opened the project-files using a text-editor to check for referenced OCX, I didn't find any.
To avoid some comments: change to .NET or any other language is not an option.
Comment: Why ever, adding the uncompiled .ctl-file seems to work. For now I can continue my work. But anyways I'm interested in a solution and the reason why it doesn't work with the current constellation.
VOTE FOR CLOSE: I've been looking at all the files, well and now I've just simply added all control-files to the project instead of creating OCX. I'll give it up. Thanks to all...
It is possible for VB6 to get quite confused when you add references to OCX files. You should really be adding an OCX as a component instead of using Project References.
Related
I'm pretty sure this is a bug in the VB6 IDE but I haven't found any definitive reference to it before...
Sometimes when I've loaded a project which has some dependency issue (missing reference, etc.) the IDE will show an error like this:
("Compile error: Can't find project or library")
Note the text which it highlighted is a call to the UCase$ function which is essentially built into the language. There's no way its library is actually missing.
Is this a known bug? Is there any rhyme or reason to the text which is selected when this happens?
Update: The standard libraries which include things like UCase() are included so that is not the actual problem. The highlight really seems to be nonsensical.
VB can do some strange things, but... check both the content and order of your References. UCase$() isn't 'built into the language' in the way you might think -- it's not in the VB runtime, but in the VBA runtime, which must be included as a reference.
My .NET program I want to use in Java depends on SlimDX, a managed wrapper over DirectX. I add it to the project references as normal without hiccup.
However, when it comes to using JNI4NET's build.cmd, I get a CS0400 error suggesting that it does not know what the hell SLimDX is, even though I referenced it properly and put it in the folder with proxygen. It cannot be found in the 'global namespace'.
This ('global::net.sf.jni4net.utils.Convertor.StrongJp2C')
is one of the offending lines.
Actually, I figured it out! It's simple, there is a -dp option in proxygen to add .NET dependencies.
... especially in the case of Non-Dialog Containers?
Hi folks,
I want to use ActiveX controls that are created in a view, not in a Dialog container, as described in http://msdn.microsoft.com/library/191es2w5%28v=vs.100%29.aspx . But in that article, the existence of the wrapper class is already supposed / not mentioned how to generate it. In the project that was handed me over, i found such generated classes.
For Dialog-Containers, the generator runs when I add a control varaible for the embedded activeX control, (again: not mentioned in msdn doc http://msdn.microsoft.com/library/w98bewhf%28v=vs.100%29.aspx ). Workaorunds are possible (eg. creating a useless dialog just for that purpose), but there must be a "clean" way in Visual Studio!? I am a little bit disappointed by the MS-Documentation I found. If somebody could give me a hint, you could make me happy...
So I thought I'd run this out there, and see if I was missing something idiotic.
I developed a small my-use-only VSIX extension, and in one of my toolwindows, I'm using the code to set the foreground/background color:
Foreground="{DynamicResource {x:Static vsfx:VsBrushes.ToolWindowTextKey}}"
Background="{DynamicResource {x:Static vsfx:VsBrushes.ToolboxBackgroundKey}}"
The vsfx: namespace is referenced as:
xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0"
I see the 10.0 referenced there, and for me, that's expected as I originally did this up in VS2010. Now that my work has made me upgrade to VS2012, the XAML designer is giving me the following error on those two SynamicResources. The error reads 'The resource {x:Static vsfx:VsBrushes.ToolWindowTextKey} could not be resolved.' and like for the second one.
Now, note that the project still builds and runs, and can be loaded into VS2012. However, the colors are all off (standard, don't match the theme that VS is set to.)
Any thoughts on what to check or look for?
Cheers -
Mike.
I ran into the same question as you guys do, and found out the follow facts:
[VsBrushes/VsBrush] v.s. [EnviromentColors]:
VsBrushes and VsBrush are basically the same thing, supported in VS2010/2012/2013;
EnviornmentColors is only in VS2012/2013, not supported in VS2010;
EnvironmentColors is still envolving, more colors will be added in for new themes; VsBrushes/VsBrush are relatively static.
[VsBrushes] v.s. [VsBrush]:
Good thing about “VsBrushes” is that it checks whether a specific color name exists during building.
Bad thing about “VsBrushes” is that is has to specify the VS namespace and assembly version in the XAML file head, which is inconvenient. (e.g. xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0")
Thanks.
Use EnvironmentColors class as it's stated here:
http://msdn.microsoft.com/en-us/library/vstudio/jj991932.aspx
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.