|
Gerry Schmitz wrote: Make a new application (server) that references the 3rd-party dll.
That is what I would suggest as well.
|
|
|
|
|
hi,
i am working on a project in which i need to transfer the data received from a query to multiple labels.
My Query: select make from dbo.cardetails;
the result of the above query is a single column with 30 rows.
now i want each row to be used as Label.text in C#
awaiting ur helpful replies.....
thanks in advance
modified 2-Aug-18 21:02pm.
|
|
|
|
|
Don't.
What if next week someone removes three rows? Or add seven? What happens to your app?
It falls over, is what.
Instead, look at using a grid based control of some form, depending on your working environment. For WinForms, a DataGridView would be good; for a website, maybe a GridView; and so forth.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
hey buddy,
but the database will be in accessable to the users.
they could only use the front end (C# form app).
so if u could help me out with my problem, it would help me alot.
modified 2-Aug-18 21:02pm.
|
|
|
|
|
If you want to make it flexible and avoid what Griff is saying you are going to need to be able to create these labels at runtime using something similar too
Label MakeLabel = new Label();
MakeLabel.Name = "x";
MakeLabel.Text = CardDetailsField;
Form.Controls.Add(MakeLabel);
please note that this code snippet is not complete as you need to add the looping of your resultset, positioning on the form etc.
But also Like Griff stated can't you use something different to display the data? such as a datagridview or listbox control?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
thanks for ur code Simon
it worked good
but the problem is tat my Labels are already present and only their names are to be assigned such tat i cud change the db in future to avoid much work and the labels get new names as soon as the db is changed and run.
modified 2-Aug-18 21:02pm.
|
|
|
|
|
hi,
i want to decompile SWF file from c#. my version is 9. any can help me in this
|
|
|
|
|
krvasanth wrote: any can help me in this Start here[^].
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Edit: Thanks to Eddy Vluggen, and Freak30, problem resolved. The solution was that I needed to create a separate .dll containing only the Interface, and then have both the host application, and the dynamically loaded UserControl, reference the Interface .dll. I define a Control Library in WinForms: it implements two Types: a UserControl, and an Interface, Iinterface. The UserControl, of course, implements the Interface.
Using the standard methods:
1. Assembly LoadedAssembly = Assembly.LoadFile(... filePath to usercontrol .dll ...);
2a. Type LoadedIInterfaceType = LoadedAssembly.GetTypes()[0]; // get the Type of the Interface
2b. Type LoadedUCType = LoadedAssembly.GetTypes()[1]; // get the Type of the UserControl
3. UserControl loadedUC = (UserControl)Activator.CreateInstance(LoadedUCType); This does load, and instantiate, the UserControl at run-time. Of course, because I've cast the loaded UserControl to the "vanilla" UserControl base-Type, any public Fields/Properties/Methods I've deliberately exposed in the UserControl definition are not available.
If I have the loading Application define the same Interface:
interface Iinterface
{
string ID { set; get; }
} Casting the UserControl instnace that shared that interface ... or any interface ... in the loading App would be pointless since that would just produce 'null.
Is there any way I can use the loaded interface Type from step 2a. above to cast the loaded UserControl to the Interface and thus expose its public Fields/Properties/Methods, etc. ?
I am aware I can use reflection to access the internal Fields/Methods that are prescribed by the interface, but I'd much rather ... if it's possible ... get everything in the UserControl that is prescribed in the Interface ... out there.
I can confirm I have a valid reference to the interface in step 2.a above by inserting this code and setting a break-point; all the expected elements are exposed:
var methods = LoadedIInterfaceType .GetMethods();
var types = LoadedIInterfaceType .GetProperties();
var fields = LoadedIInterfaceType .GetFields(); To use that old cliche: "what am I missing, here?"
thanks, Bill
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
modified 30-Jan-15 11:02am.
|
|
|
|
|
A placeholder to program against in the main application.
Move the interface to another assembly and reference that from the main application; next you load usercontrols that implement the interface - but you'd loose the ability to update the interface without updating the main executable. You might also want a factory somewhere that determines what class to instantiate if you pass it an interface.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks, Eddy; I will experiment with creating a .dll containing only the Interface, although it seems weird to have to do that
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
BillWoodruff wrote: although it seems weird to have to do that It sounds weird to not do that, from my point of view.
What would you use as a base-class to reference the control in the application? Both UserControl and Object will not know any specifics - you'd have to use reflection to invoke anything, which defeats the reasoning on using an interface.
It sounds like you want to have a "general" way of talking to dynamic loaded UserControls.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: It sounds like you want to have a "general" way of talking to dynamic loaded UserControls. I would have guessed ... before today ... that given a valid reference to a Type (an Interface) one could somehow cast another valid reference (to an instantiated object that implements the Interface) to the Interface.
But, looks like this is not possible.
Thanks again, for your reply.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
One can; if your IUserControl is in assembly A, and the implementation in B (with a reference to A), you could use A from your mainapp to reference the UserControl.
I don't know whether it would accept a "similar looking" interface from another assembly, even if they have the same name - AFAIK, they'd be treated as different types since they are located in different assemblies.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I second the suggestion of moving the interface definition a .dll shared by the executable and the control library. The interface shouldn't change that often.
Also I wouldn't call the interface Iinterface. IUserControl is probably more fitting.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Thanks for your reply. I'll try it. I used a nonsensical name because I was just pasting in the minimal amount of code, to keep the post brief.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
Hello everyone,
In one of my project i have a requirement of getting OS Name,version information etc of local network.
Is anyone have any idea of getting Non-Windows OS infomation from Windows machine using c#,c++,or Win32 API.
Thanks in Advance.
Regards,
Jitendra Singh
|
|
|
|
|
A network does not have OS information, it's just a bunch of wires connecting a group of systems. And what exactly do you mean by "Non-Windows OS infomation from Windows machine"?
|
|
|
|
|
If you mean "I want to run software on my Windows machine to find out what OS all the other equipment on my network is running" then AFAIK you can't. Partly because some if it is unlikely to be a computer at all - printers, router, dedicated IoT devices and so forth; and mostly because security on most systems prevents it. If you advertise your OS, then you advertise your vulnerabilities - so it's kept within the machine for the most part to make it harder for attackers. You can guess by checking which ports are open - different OSes tend to open a different set of ports by default, so if they haven't been changed it might be indicative, but it won't be conclusive.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I mean i will provide a IP range that belongs to same local network.
For instance i give IP range 192.168.1.20 to 192.168.1.30
IP OS
192.168.1.20 Windows 7 x64 bit
192.168.1.21 Linux OS
192.168.1.22 Mac (Lion 10.7) x64 bit
192.168.1.23 Windows 7 x32 bit
I hope now the picture becomes more clearer.
Regards,
Jitendra Singh
|
|
|
|
|
And as I said: AFAIK, you can't do that.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The only way that springs to mind depends on you having these machines running under Active Directory, with none Windows machines connecting to AD via Samba. If you have this, you can retrieve the details about the OS using AD services.
|
|
|
|
|
I've outsourced my enterprise level project to a freelancer and I got a quite good setup too. But now that contract has finished and the person has also moved to a new technology, in other words not willing to extend the contract. Now I'm looking into this code on myself. I do have a 2 3 years of background in C# and MVC. Below is a rough idea of my application architecture. Hopefully I've tried my best to abstract the architectural details of an enterprise level application. Please let me know if you need further brief on any of the questions.
All my Entities are defined as C# POCO classes as:
public class Product : BaseEntity
{
public int ProductId { get; set; }
public string ProductName { get; set; }
}
Now I've a IDbContext like as :
public interface IDbContext : IDisposable
{
IDbSet<TEntity> Set<TEntity>() where TEntity : BaseEntity;
}
Base Entity is a Partial POCO class that each POCO entity is inheriting. Here is a class that implements this IDBContext as:
public class MyObjectContext : DbContext, IDbContext
{
public new IDbSet<TEntity> Set<TEntity>() where TEntity : BaseEntity
{
return base.Set<TEntity>();
}
}
Now I've defined a IDbContextFactory that is responsible for providing the DBContexts as :
public interface IDbContextFactory
{
Lazy<IDbContext> CreateDbContext();
}
The class implementing this IDBContextFactory interface is having below structure :
public class MyDbContextFactory : IDbContextFactory
{
public MyDbContextFactory(string dbConnectionString)
{
_dbConnectionString = Settings.DbConnectionString;
_dbContext = CreateDbContext();
}
public IDbContext CreateDbContext()
{
IDbContext dbContext = new IDbContext(() => CreateNewContext());
return dbContext;
}
private MyObjectContext CreateNewContext()
{
return new MyObjectContext (_dbConnectionString);
}
}
Here IRepo Pattern comes into role as:
public partial interface IRepository<T> where T : BaseEntity
{
T GetById(object id);
}
Now the Repository class implementing this Interface is as below :
public partial class EfRepository<T> : IRepository<T> where T : BaseEntity
{
private readonly Lazy<IDbContext> _dbContext;
private readonly IDbContextFactory _dbContextFactory;
private readonly Lazy<ObjectStateManager> _objectStateManager;
public EfRepository(IDbContextFactory dbContextFactory)
{
_dbContextFactory = dbContextFactory;
_dbContext= _dbContextFactory.CreateDbContext();
_objectStateManager= new Lazy<ObjectStateManager>(() => ((IObjectContextAdapter)_dbContext.Value).ObjectContext.ObjectStateManager);
}
public T GetById(object id)
{
return this.Entities.Find(id);
}
}
Till now we are done with the Infrastructure level setup for DB Access Management. Now the thing is to utilize this setup into Controllers(as I'm having directly accessing Repositories from Controllers) to as below :
public CountryController(Lazy<IRepository<Country>> countryRepository)
{
_countryRepository = countryRepository;
}
public Country GetCountryById(int id)
{
Country country = _countryRepository.Value.GetByIdNonProxiedAsync(id);
if (country != null)
return country;
else
return null;
}
Hopefully all above is clear. Now here are the some questions that I need to be answered :
1) Why we are having this layered flow like as:
IDBContext -> IDBContextFactory -> IRepository <T>
and then finally using this IRepository into Controllers for accessing Data objects. In other words why we are relying on Interfaces instead of actual Class Objects while implementing Constructor Injection for Country Controller ?
2) Is this the correct approach for a Enterprise level Application as it should be much scalable for future purpose. If there is any other then I would be glad to know about that ?
3) In Controller's constructor I've used Lazy>, so what's the purpose of this Lazy and is it beneficial actually If yes then in what way ?
modified 29-Jan-15 8:20am.
|
|
|
|
|
Run Run! Watch out for the flamethrower!
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Thanks mate. Please find it out yourself. I posted this question here by mistake. I appreciate your response.
|
|
|
|