|
Caveat - I have not used MEF or plug ins.
Uhm that does not seem to make sense, the host application needs to code against the functionality of the plug in, hence the required interface. I am scratching my head trying to figure out a use case for not having an interface for the plug in.
I will be interested in other responses 
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I don't think you can get rid of the interface. How is the host app supposed to know how to call the methods in the plug-in, and what they do, if the plug-in doesn't implement some kind of interface?
|
|
|
|
|
I can see where you are going with this but you have the problem inverted. It sounds like you have a contract that you have created in a plugin assembly and you are trying to use MEF to load that assembly, which has already been linked with the application. Rather than doing this, you would normally have the interface defined in an assembly that just contains contracts. Both the plugins and the application host will be linked with that assembly but they will not share any code and the application host does not have to know anything about the plugins other than that they share an interface. That way you keep them both from knowing about each other, as they rely on the intermediary.
This space for rent
|
|
|
|
|
When I put a control( for example a textbox) into the application form's environment from the Toolbox Visual 2010 component inside the code environment but it does not recognize that control inside the code environment But yesterday it recognized that. :wtf:
|
|
|
|
|
Do you have a question ? Is there a problem now ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Start by trying to read what you wrote - I can;t make any real sense of it!
Then think about the sequence of operations you performed. If I read it right - and I probably didn't - you added a control to a form by drag and drop from the toolbox. And yesterday, it worked. But today, your code can't reference the control by the name it had yesterday.
If so, start by opening your form in design mode.
Does it open without an error message? If not, start praying, and look at the appropriate .designer.cs file together with the error list and see what has happened there.
If it opens ok, is the control still there? If so, look at it's properties, and check it's Name. Is it what it was yesterday?
If it isn't, then you need to look at the files themselves and see what happened in (and to) the .designer.cs file - did you save and exit VS correctly, or was there a problem?
Sorry if that all sounds vague, but ... so is your description, and we can't see your screen at all! 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Good Year to all,
I have a question and your help would be important. I am creating a graphical interface (C #) that communicates via IP with a relay module.
I am having difficulty sending the IP commands to turn the Relays off and on.
The command must include IP address / Password / command: example - 192.168.1.4/30000/00
Relay 1-8 Bit Command:
http: // IP / password / 00: Relay-01 OFF
http: // IP / password / 01: Relay-01 ON
The command must be sent all of it at once.
Thank you very much
|
|
|
|
|
Hi,
setting up a communication between two devices may be hard to bootstrap; if at first it doesn't work you typically have too little information to figure which side is failing and what should be done to remedy the problem.
However if your target device already exists, and expects HTTP GET commands (as your post suggests), then you should be able to test it from any browser, e.g. Google Chrome.
Mind you, the peripheral when receiving a GET command, is normally expected to return some web page, i.e. some data that has this structure:
<html>
<head>
... the head may be empty
</head>
<body>
... some meaningful text goes here
... counter = 102 (*)
</body>
</html>
it is wise to take care of that right away, as it will help you in debugging the system.
(*) I would also suggest to include a counter value, so each time a page is returned it is different from the previous one, in a predictable way.
Similarly I also suggest you give your peripheral an observable something, say an LED that toggles each time a page request is received (that is a one-bit counter!).
Now I see some potential problems:
1. your "command" is passed entirely as one of many possible web page URLs, and it seems to contain spaces, which are not allowed in a URL (i.e. they should be escaped, this turns every space into the sequence "%20")
I find it easier to avoid all special characters, including spaces.
2. I would prefer to work with only one page, and pass all the details (relay number, relay state) and even the password as parameters; parameters are key-value pairs, starting with a question mark and separated by ampersands, so it might look like:
http:
3. Depending on what devices and networks might sit between your PC and your peripheral, there may be a risk of your command never reaching your peripheral, due to caching somewhere on the way. This can be remedied by some META tags in the HTML head (very tricky to get a general solution), or by adding an extra parameter which is always different, like:
http:
As the URL of consecutive commands would all be different (having an incrementing sequence number), caches can not intervene.
4. You should be aware that an HTTP command may reach your peripheral (a) not at all (internet offers no guarantees), (b) just once, (c) many times. A browser is allowed to automatically resend a command that didn't get answered soon enough. So the concept of your peripheral and its command language must allow for unintended command duplication.
A safer way is to use an HTTP POST command rather than the standard HTTP GET command. This too can be achieved through a browser (e.g. there are extensions to Chrome for this purpose).
Once you got all the above up and running fine, you can try and create C# code that replaces your browser. There are at least two ways to handle this:
1. using a WebBrowser [^] Control, which basically is the kernel of Internet Explorer with an API so you can set the URL and request a page, view it, etc. When you're done debugging, the WebBrowser can remain off-screen or be otherwise invisible.
2. using some classes from the System.Net namespace, such as HttpWebRequest[^]. I suggest you google for some examples.
Hope this helps
modified 4-Jan-19 21:58pm.
|
|
|
|
|
How to send meeting invitation to an user using google calendar API and invitation send by email?
|
|
|
|
|
Check the Google API documentation.
|
|
|
|
|
|
I was debugging a Class that uses a Stack, and seeing puzzling results ... in terms of Stack contents ... when I realized a public read-only Property 'getter was using 'Pop: so, every time I inspected an instance of the Class in break-mode, the Stack was popped.
I was wondering if there is a compiler directive, or other means. to detect Class instance state being accessed in break mode, and block the 'Pop. My searches have not found an answer, yet.
thanks, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Popping an item off a stack is a run-time instruction; how could the compiler prevent that occurring? And that instruction should only execute in break mode if you step through it. I think we need more details.
|
|
|
|
|
thanks, Richard,
Keep in mind that I have set a break-point, and I am "opening" the current state of the Class instance to browse it by hovering over the source code using the IDE's inspector to view the current values of variables, and properties. So, there is a level of indirection in the code execution here.
My (weak) hypothesis that run-time break mode and instance drill-down detection in VS may be possible is based on the assumption that there's always something possible I don't know
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 4-Jan-19 4:45am.
|
|
|
|
|
I have been debugging my (sometimes poorly designed) code with Visual Studio for years, and I have never had an occasion where inspecting a variable makes it change value.
|
|
|
|
|
Quite likely because you had the common sense to never pop a value off a stack ... and return the popped value ... in a property getter
Or, if you did that, and set a break-point and then inspected the class instance ... you weren't perturbed by the inspection calling the getter, and you were not crazy enough to imagine Visual Studio might provide a way during paused program execution to look around without side-effects.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I cannot imagine how this is happening. Inspecting variables should not disturb them. The whole point of the debugger is that nothing changes unless you tell it to.
modified 4-Jan-19 12:38pm.
|
|
|
|
|
A getter property isn't a variable and doesn't have a value, it is a bunch of code that returns a value, so yes when asked for it will execute whatever code is present. That is good enough reason not to create side effects in a getter property.
|
|
|
|
|
Yes, of course it is, something I need to test. 
|
|
|
|
|
Hi Bill,
a getter should not change object state, reading a property isn’t allowed to change anything.
That is why Random.Next is a method, not a property.
|
|
|
|
|
Thanks, Luc, Are you saying that a Property 'getter can't change anything, or are you expressing your opinion that a 'getter should not change anything ?
The issue here is the side-effect of browsing class instance values during a "break-state."
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
a getter's role must be restricted to returning information about the object, it should not modify the state of an object, nor have any other side effects.
IMO a getter with side effects would breach OOP principles.
MSDN[^] states: "It is a bad programming style to change the state of the object by using the get accessor".
|
|
|
|
|
I always appreciate your opinions, Luc !
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
|
Thanks, Richard ! I have 'come around' to thinking that the Property should be replaced by a Method whose name makes it obvious what state will be changed. And, maybe I shouldn't be surprised at the side-effect of a 'getter whose value is inspected during a 'break state ! 
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
