Hi I created one app that show you all your devices in your network. I would like to encapsulate all this code and controls in one "custom control" for use it in others apps.
I only find information about WPF custom controls, however when I tried to create a WPF custom control and then reference it to my Universal App, I got an error. I have searched about it and It seems that you can't use WPF controls in Universal Apps.
My idea is create something like "NetworkDevices", then I would put in my Universal App Main XAML:
<NetworkDevices Property1= .. Event1=........ ></NetworkDevices>
and then I would have my custom control embebed in my Universal App.
Thanks for your time.
Update:
Visual Studio Solution and the error
What you need is a Templated Control in a Universal Windows class library (so it can be reused in other apps).
I suppose you know how to do the rest (as you've created WPF custom controls, but as a reference you can use this MSDN article as well to guid you through step by step.
Related
I am trying to do basically what it says in the title: I have created a class library (dll) using .NET 6.0 and I would like to add that as a reference in an Excel/Access VBA document. I diligently followed the steps here:
https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
No matter what I try, I cannot add the resulting dll as a reference in Excel. I just keep getting the message: 'Can't add reference to the specified file'.
A bit more info: I am able to create the Assembly.comhost.dll file, and I think I have done everything correctly, but no joy.
This is rather frustrating, as doing this in .NET Framework is but a click of a couple of checkboxes. In .NET Core (.NET 6) It seems to be a bit of a nightmare. Also, being able to create a tlb from the dll was always a perfect confirmation that you would be able to add your reference in Excel.
ANY help is most welcome!
Thanks!
in the tutorial you hav ementioned, ther is a topic "Register the COM host for COM". here a file named "ProjectName.comhost.dll" is used to register the assembly to the registry as a COM type library.
After doing this, i could the assembly in VBS with the fowing conde:
set projectObject = CreateObject("ProjectNamespace.ProjectClass")
newValue = projectObject.ComputeNewValue("abc")
Right now, I was not able to establish a reference to that type library in my Excel 2016, but the code sample works in VBA as well.
I could also in VBA
Set projectObject = CreateObject("COMServer.Server")
MsgBox projectObject.ComputePi()
with this repository : https://github.com/dotnet/samples/tree/main/core/extensions/COMServerDemo
But that works only with Registered COM not with RegFree COM (Go check README).
Not every component is a suitable candidate for use under Reg-Free COM. A component is not considered suitable if any of the following are true:
The component is an out-of-process (ActiveX EXE) server. Only DLLs
are supported.
The component is a system component or part of the operating system,
such as XML, Data Access, Internet Explorer, or DirectX® components.
For example, you should not attempt to isolate components such as
Microsoft XML (MSXml.dll) or Microsoft Internet Controls
(SHDocVw.dll). These components are either part of the operating
system, or can be installed with a separate redistributable package.
The component is part of an application, such as Microsoft Office.
For example, you should not attempt to isolate components such as the
Microsoft Word Object Model or Microsoft Excel Object Model. These
two components are part of Office and can only be used on a machine
that has the full Office product installed on it.
The component is intended for use as an add-in or a snap-in, such as
an Office add-in or a control in a Web browser. Such components
typically require some kind of registration scheme defined by the
hosting environment that is beyond the scope of the manifest itself.
The other problem is an arbitrary application may not be designed to
recognize isolated components, as it probably doesn't have a way to
reference your component through a manifest.
The component manages a shared physical or virtual system resource.
For example, it could manage some kind of data connection shared
between multiple applications or a device driver for a print spooler.
Source : https://social.msdn.microsoft.com/Forums/en-US/cc08575d-3506-4a0f-a9e2-f23c2162ad38/using-net-excel-addin-with-registrationfree-com?forum=innovateonoffice
But I couldn't find a way to add it in Excel as a reference.
I have built two projects in my VS solution. One is a MVC web applicaition and other one is a standard C# windows form project. I want to transfer data both ways. For exmaple the input from my MVC web application to the form and then output back to my web application from the C# form project. However, I can only do refrenceing from one side and access the static variblias of only one project from another. To achieve my goal, I need to do circular referencing which VS is not allowing me. Is there a workaround to my solution.
PS: My main goal is to access all the static members of every class into every other class in my whole solution.
Separate the static functions in a separate library and then reference that from windows or web application. That way you will also know what are common functions and what functions are specific to those feature or class.
It is not a good design to let "access all the static members of every class into every other class". It violate OOPS principles.
If its shared data save it to any repository and access it from there from both of your application.
Apologies if this has been answered, but I could not find a similar question:
I am developing a webpart for MOSS 2007. I am using WSPBuilder to built a visual webpart (ascx) and everything works fine, but the development/debug cycle is just painfully slow, so I'd like to know if it is possible (without being too painful) to develop the user control faster using an .Net Web Application project with all of the nice F5 debugging, then import the final product into my SharePoint visual webpart.
The user control interacts with a LOB system (SQL) and does not reference the SharePoint API at all. (The reason I am building this as a webpart is because I don't need another web app to run this one page, so putting it into a webpart on a new webpart page on my existing site is the best solution IMO.) I would obviously need to import (reference?) my data access classes into my "temp" web app, but think that would not be too much trouble.
I realize this will be extra effort to get this set up, but am thinking the payoff will be reduced development time of the actual user control using a little web application vs having to use the compile/build WSP/deploy WSP/reset ISS/test/make a change/repeat cycle that MOSS requires. (I guess SP2010/VS2010 has spoiled me with the native SharePoint tools available.)
Update:
I have successfully built a simple web app with one page and loaded up my UC on the page. (I had to comment out all of the Sharepoint Import and register statements that WSP Builder added to the UC for me when I created the webpart.) I added references to my utility classes (which I left in the obj\Debug folder in the original SharePoint project). It took me a while tinkering with everything to get it to work, but the steps ended up being pretty simple and I think I can replicate the steps quickly for future projects. Once it was set up, I was able to rapidly design the UC and build in the UC functionality using the typical F5 debug cycle. Unless someone can show me why this is not a good idea, I plan to repeat this for future projects! Thanks to everyone for thier input.
.
Update 2
Well, I am not sure what I did but moving the UC back into SharePoint proved to be troublesome. The first time I did it, I spent several hours getting it to work in SharePoint, making me question whether it was worth it. However, I am stubborn and tried it again. This time, I only copied and pasted the markup below the "header section" (the part with all of the <%# . . . %> statements) in the ascx file and everything went perfectly. I think I must have changed something inadvertantly the first time. I think I will continue this pattern as it is so much faster to build and test the UC in an ASP.NET web app. (Again, this only works if you are not referencing the Sharepoint API anywhere in the UC.)
The answer here is the SmartPart. It is perfect for just the scenario you are describing. Very easy to create a Usercontrol using "vanilla" ASP.NET and have it work as a webpart in SharePoint. I've outlined the steps to migrate from ASP.NET webpage to statically bound SmartPart on my blog.
What you intend to achieve is surely a nice idea.
Just remember to strong name your user control, drop it in your Server's GAC, update SafeControls section of your SharePoint 80's web.config.
All these setps are one off, after each successive builds (of your web control), you have to just deploy the control (used forcede deploy) in GAC and reset IIS.
You can add this control to toolbox in VS by selecting 'Choose Items' and selecting ther assembly you just deployed.
In addition you can create a test ASP.NET page to test the functionality of your control.
Hello previously i was using VC++ 6.0 and MFC where i used Microsoft Communication Control 6.0 for serial communication its fine.But now i am using vc++.net 2003 and MFC, i added Microsoft Communication Control (MSComm1) but in class view there is no CMSComm class will creating . But in VC++ 6.0 if i add the this ActiveX Control.The CMSComm class will created by default where i can call member functions like SetPortOpen() , GetPortOpen() .
so any body tell me how to insert the MScomm control along with class.
Thanks in Advance
You may be having problems because this Microsoft update set the ActiveX killbit on the control. It will no longer function. MS suggests that we use a newer version of the control or the API.
EDIT: I did this with VC# and am not sure if the steps are the same with VC++. I need to install it and try it before providing a better response.
Since serial port support wasn't added to .Net until version 2.0 I had to do the same thing for .Net 1.1 apps. In my project I added a reference to MSCommLib and added the MS Communications Control, version 6.0, to my toolbox. After dragging one onto the form I was able to program against it. You should also have a reference to AxMSCommLib, AxInterop.MSCommLib.dll (COM interop not port).
Sorry, I opened the project and can't find a way to add it to the Class View, but once you have a reference and create a variable like "private AxMSCommLib.AxMSComm com;" you can use the intellisense to see the methods and members of the object.
You can also see these with the Object Browser. If you have the reference set, open the object browser and then click on AxMSComm. All of the members should be listed in the pane to the right side. There isn't much help for how to use each of the members here.
Microsoft Visual C++ 2008 Feature Pack has ribbon menu support. Is it possible to make use of that in an existing MFC application that was not created with a ribbon menu?
It certainly is possible to take an existing MFC application and update it to use the ribbon in the MFC Feature Pack, and I've done this myself.
There are a couple of walkthrough articles on MSDN here that show how to do it, using the Scribble MFC sample application that you may be familiar with.
In essence, what you need to do is change your code to use the Feature Pack base classes instead of the standard MFC base classes - for example, replace CWinApp with CWinAppEx, CFrameWnd with CFrameWndEx, etc. Then you can add CMFCRibbonBar and CMFCRibbonApplicationButton objects to your main window class to create the ribbon itself. To get started I'd suggest downloading the Scribble sample and following the walkthough articles.
I hope this helps!
In addition to the resources pointed out by ChrisN, I recommend creating a new MFC application that includes a ribbon and examining the generated code..
Yes, it is surely possible to use the ribbon classes provided with the MFC Feature Pack.
A basic introduction is available here: Quick Tour Of New MFC Functionality and a more detailed tutorial can be found here: MFC Feature Pack Tutorial.
However, be aware that there is a rather strict license attached to it. For the conditions see Licensing the 2007 Microsoft Office User Interface and this related discussion on SO.