|
First you need a fly, it is best to stun the fly by wacking it gently on the head, not to hard as it gets all squishy and spiders don't like squishy flies. Now I suggest you tie the fly with a piece of cotton and dangle him over the monitor, I find blue tacking the cotton to the top best. Wait very patiently an you may get a spider wander by and snap your fly.
BTW remember to turn off your screen saver you don't want the miss the spider when he comes looking for your fly.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
But asp nets are way too heavy for catching spiders. You need web technology for that.
ok, late on Friday....
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Yeah but you should be able to cast your asp net to a web two right out of the box.
Less late on Friday but an early start on the weekend
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Sorry but I must object. Spiders do like flies squishy, but only on the inside. The outside of the fly should remain crisp and crunchy.
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
Here's a sample in Flash[^]
V.
|
|
|
|
|
Just in case you wondered why you are being down voted: Your question is not very precise, in fact it is unclear and does not even belong in this forum. This is the C# forum and there is a forum explicitely for ASP.NET[^] questions.
Best Regards,
—MRB
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
We generally try not to introduce bugs in our software, but that's just me, it could work for you.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
hi
how can i multi inherit with interface
please sample
|
|
|
|
|
interface A { }
public class B { }
interface C : B, A
{
}
You can only inherit one class, but you can inherit multiple interfaces. Just always put the class before the interfaces when inheriting it.
|
|
|
|
|
Multiple inheritance is bad, mmkay? We prefer composition[^] 
Bastard Programmer from Hell 
|
|
|
|
|
Multiple implementation (of interfaces) is fine, though. A class often actually is (the test for whether inheritance is appropriate) several things defined by simple (one aspect, ideally) interfaces, and implementing each of them makes sense. For example some sort of data model class could easily be an INotifyPropertyChanged, an IEnumerable<T>, and also some kind of IDataProvider interface within your own code. Or just look at the declaration of the collection classes in the framework.
|
|
|
|
|
BobJanova wrote: Multiple implementation (of interfaces) is fine, though.
Multiple inheritance isn't even possible. Yes, you can implement multiple interfaces, but please don't use them to create an object that simply "binds" a few objects together; that's when a composition would be preferable.
The question being phrased as it is, I'd guess that he's trying to combine an IEmployee and a IManager.
..thanks for the reminder though
Bastard Programmer from Hell
|
|
|
|
|
What you are talking about isn't multiple inheritance, it's multiple implementation. Take the following interfaces
public interface IMyInterface
{
void DoSomething();
}
public interface IAnotherInterface
{
void DoSomethingElse();
}Now, you have a class that needs to implement both of these. To do these, you add them to the class definition and then you provide an implementation for the interface methods. It looks like this:
There you go - you have now implemented two interfaces in the same class.
<div class="signature"><small><p>Forgive your enemies - it messes with their heads</p>
<p><a href="http://peteohanlon.wordpress.com">My blog</a> | <a href="http://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=213147">My articles</a> | <a href="http://peteohanlon.wordpress.com/moxaml-power-toys/">MoXAML PowerToys</a> | <a href="http://www.molosoft.com/">Mole 2010 - debugging made easier</a> - my favourite utility</p></small></div>
|
|
|
|
|
I am fixing a tcp listening application which is accepting messages on a port. Once the message arrives it is sent to a queue using MSMQ. The message is then received from the queue and put into another queue. So it goes like so:
Message arrives > Message is sent to queue (Q1) > Message is received from queue (Q1) > Message is sent to another queue (Q2)
The same application is doing all this. I am not sure why this has been implemented this way.
The idea is to accept messages in format x, convert them to format y and send it to another application.
I understand the above might be unclear but I am still analyzing the code. I am starting to think the implementer did not understand the concept and use of message queues really well. What do you think?
<b>CodingYoshi</b>
<i>Artificial Intelligence is <b>no</b> match for Human Stupidity.</i>
|
|
|
|
|
if there are three operations:
1. receive data
2. convert data
3. transmit data
then I can imagine a lot of situations that would require or want these to happen independently, i.e. on separate threads and/or using asynchronous I/O; and then having queues between 1 and 2, as well as between 2 and 3, seems logical.
OTOH if nothing is happening in between "Message is received from queue (Q1)" and "Message is sent to another queue (Q2)", then I would doubt that is the most logical and efficient approach.
|
|
|
|
|
I would avoid message queues at most any cost. They seem like a solution looking for a problem, or maybe a solution to a problem that has since moved on to a better solution.
|
|
|
|
|
PIEBALDconsult wrote: solution to a problem that has since moved on to a better solution
I'm interested to hear your thoughts on this. The last time I used MSMQ was in 2000 and using VB6.
It sounds like a good solution to the above problem if he does not control the source and final destination but still has to impose some formatting on the data between the 2 systems.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I was speaking in general. Maintaining an existing system is one thing, but I wouldn't (and haven't) create a new system based on message queues.
On my last job I had to create a number of processes (Windows Services) and some had to pass data back and forth, but I simply had them write data to the appropriate database tables.
On my current job, I'm helping maintain a queue-based system (in-house developed?). Again, some applications may need to pass data to other applications. So messages are written to queues to be read by the other application. But I see no benefit of using queues over simply writing the necessary data to a table that the other application reads. In my opinion, the whole message queueing system is a needless extra middleman that merely adds complexity.
|
|
|
|
|
PIEBALDconsult wrote: no benefit of using queues
That I can understand queues are sooo 90s. I cannot imagine designing a solution with queues today but back then they were a valid solution.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Wow, we agree on something else. ![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
|
|
|
|
|
It's there to ensure durability (assuming MSMQ is setup to be durable). There are now other options but prior to .NET 3.x it provided a durable solution for third party providers. It also works well in remote locations where connectivity isn't assured. Connectivity may not be an issue here but if the message received, somehow crashes the service/server or the server falls over for whatever reason, the message should still survive.
"You get that on the big jobs."
|
|
|
|
|
I understand, however, how can the message survive if the system crashes before being inserted into a queue? I guess once it is inserted, only afterwards it can survive.
I studied the code more and looks like nServiceBus is used as well. Any idea why nServiceBus is used? I did some research and I am starting to think nServiceBus is similar to WCF but has differences. Also nServiceBus is built using MSMQ so why are the messages being inserted into queues again if nServiceBus is taking care of that?
<b>CodingYoshi</b>
<i>Artificial Intelligence is <b>no</b> match for Human Stupidity.</i>
|
|
|
|
|
If the system crashes, before inserting into queue there isn’t much you can do. Hopefully the sender is expecting a response and so will assume that the message was not successful. If all is good, receive message, queue to MSMQ and then respond that message has been received. nServiceBus I know nothing about, sorry.
"You get that on the big jobs."
|
|
|
|
|
RobCroll wrote: in remote locations
Sure, but I'd likely roll my own socket messaging engine that the applications don't need to know about.
|
|
|
|
|
It was a while ago but the way I remember using MSMQ. The remote server would run a service that handled the tcp/ip communications with the remote applications. The remote server also had in and out MSMQ's. Another service would manage the MSMQ's in the city location. We didn't worry about testing for connectivity, MSMQ managed the "bridging" for us.
Hope that helps but it was a while ago. Also each OS had it's own version of MSMQ. That may not be the case now but ensuring the queues were durable could be problematic.
"You get that on the big jobs."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
