|
|
I need some more help i don't know c at all, i just jumped into c#
Da Intern
|
|
|
|
|
Look at the second link. C#. That in fact takes you to a whole scope of usable algorhithms. Algorhytms are language independent. IOW they work the same. Just follow the logic step for step. I'm pretty sure (well I dont) most people try to NOT remember algorhythms, hence I (or most others) cannot help you. A beeter bet would be to ask help form a mathematical message board if Google does not provide enough clarity.
leppie::AllocCPArticle(Generic DFA State Machine for .NET);
|
|
|
|
|
go back to university, people/lab who research on path finding, routing and the like should be able to provide you with something. Look for games, bandwidth/network traffic control/optimization. Although universities don't usually provide production quality code and it's probably in c++ - just expose the code to Managed C++, and use from C#
Norman
norm
|
|
|
|
|
norm wrote:
go back to university
Or maybe get on a uni site.  My, but there's gold to be found there if you take the trouble to mine it.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Looking at the subsequent thread, I'm not sure what you're asking for. Are you asking for an explanation of Dijkstra's algorithm? Or for an explanation why a particular implementation of D's algorithm does what it's supposed to do?
Cheers, Julian
Program Manager, C#
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
|
|
|
:-DBasically i'm trying to find the code for dijkstra's algorithm in c# so i can use it in a program im making. I understand the concept but im just having alot of trouble writing the code for it.
p.s. Thanks alot
Da Intern
|
|
|
|
|
So take it step by step.
Dijkstra's algorithm is a "shortest path" algorithm for a network of nodes. So it requires a collection of nodes (doh!  ) or vertices connected with edges that have costs associated with them. So think about how that could be represented. A vertex could be a simple class, the edges could be a class containing the from vertex, the to vertex and the cost. Or you might use a sparse matrix of vertices where the edges are defined at the intersection of column and row vertices.
It also requires a container into which you can push all the nodes and that will pop them out in lowest cost order (the cost of a node being the cost of the path to get there from the start node). Think about how you'd write that (it's called a priority queue).
That's pretty much it, just some glue code to run the algorithm and you're away.
So look at any code you find on the web that purports to implement Dijkstra's and try and identify these two parts and understand how the programmer implemented them. Try and find a Java example rather than a C++ example, you'll have a better chance of understanding it.
Cheers, Julian
Program Manager, C#
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
|
|
|
I couldn't figure out why the .xsd schema generated by the Visual Studio for a typed DataSet (I declared SqlDataAdapter for every table in my database) has fields with some properties, different from those declared in the database:
for example, default values were not specified in the schema, though there were defined in the database.
Can anybody help me with this one? Are there any fine-tuning options I have missed (besides manual editing, of course)?
Thanks for help.
|
|
|
|
|
When I click Ctrl-C in my control inherited from TextBox I get following exception (and "c" letter is written to the TextBox):
The current thread must set to Single Thread Apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it
in ProcessDialogKey() method. Stack trace is:
System.Windows.Forms.Clipboard.SetDataObject(Object data, Boolean copy)
System.Windows.Forms.Clipboard.SetDataObject(Object data)
System.Windows.Forms.DataGrid.ProcessDialogKey(Keys keyData)
Any other OLE calls (Ctrl-V etc.) doesn't cause such errors.
May be someone know what happens and how to avoid it?
Thx in advance
Hi,
AW
|
|
|
|
|
By the way, are you sure that you do have [STAThread] on your Main?
|
|
|
|
|
Thx, it misteriously disappeared
Hi,
AW
|
|
|
|
|
simple put
[STAThread]
above the Main function
try that first
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
One question, What's the point of Remoting if you need to "Add Reference" -- if you need to add reference (to gain access to assembly meta data), then why bother going thru layers of overhead with remoting? Just package your code in a class library dll and on the client side, just instantiate the object - no need to Activator.GetObject. Just:
MyObj obj = new MyObj();
I think I am missing something here. okay, remoting lets you run your remote object in a separate process/app domain but anything besides that?
Thanks!
norm
|
|
|
|
|
There isn't much of a point if you have to include the server implementation with the client. But it is possible to split it up so you'd have 3 assemblies:
Shared - contains interfaces or base classes implemented by "Server"
Server - references "Shared" and implements "Shared" assembly's interfaces or base classes
Client - references "Shared"
If you want a ton of information about remoting you should get Ingo Rammer's book, Advanced .NET Remoting. I'm on Chapter 4 now and I've been really impressed with it. You can get chapter 2 from his website[^] which covers the basics of remoting, while chapter 3 shows some caveats to what was shown in chapter 2 and offers ways through and around them.
Chapter 4 so far is concentrating on how to use configuration files to get around having to hard code everything in the server/client.
James
"My words but a whisper -- your deafness a SHOUT.
I may make you feel but I can't make you think." - Thick as a Brick, Jethro Tull 1972
|
|
|
|
|
oooo... there're too many books that I need to read in too little time....
life's short, ....
anyway, QUOTE:
Shared - contains interfaces or base classes implemented by "Server"
Server - references "Shared" and implements "Shared" assembly's interfaces or base classes
Client - references "Shared"
QUESTION: so, basically, you have two dll and two exe:
1. RemoteObject.dll
2. Interface assembly of remote object (RemoteObjInterface.dll)
3. Server (RemoteObjServer.exe):
a. References the interface assembly (2)
b. Register channel, register type.
4. Client (RemoteClient.exe):
a. References Interface assembly (2)
b. Do you still use Activator.GetObject()?
Just thinking how to implement interface.. By the way, you still need to refernce interface assembly. I guess the point of remoting is that RemoteObject do run in different process/app context/server - meaning it has access to resources on a remote server (database/file/AD/registry...etc). if it wasn't that, there's not much of a point for remoting (am i missing something here?)
norm
|
|
|
|
|
norm wrote:
Do you still use Activator.GetObject()?
Yes/no, for certain remoting scenarios you use it; in other cases you can use configuration files and some generated wrappers to get around it.
norm wrote:
meaning it has access to resources on a remote server (database/file/AD/registry...etc). if it wasn't that, there's not much of a point for remoting (am i missing something here?)
Another use is to have a single place to keep your code up to date. For example, you could use remoting to host a business rules library or data access library. If rules change you can update the assembly on the server but not have to update each client.
Another would be to simply keep your code from even being on the client computer. This is similar to the web service approach, but you don't have to host through a web server.
James
"My words but a whisper -- your deafness a SHOUT.
I may make you feel but I can't make you think." - Thick as a Brick, Jethro Tull 1972
|
|
|
|
|
Thanks. But I'm having some trouble separating interface with remote class. Calls to:
SERVER SIDE:
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(nsCRemoteObj.CRemoteObj), //QUESTION 1: I still need to reference the remote object - as opposed to the interface??
"CRemoteObjURI",
WellKnownObjectMode.SingleCall //QUESTION 2: Since we'll be communicating with client via "interface", NO Singleton?
);
AND
CLIENT SIDE:
IRemoteObj obj = (IRemoteObj) Activator.GetObject(
typeof(CRemoteObj), //QUESTION 3: Opps, I still to reference the remote object assembly - in addition to interface assembly!??
"http://localhost:8085/CRemoteObjURI"
);
Any idea?
**********************************************************************
code structure below if you're interested. (Questions are highlited --> "QUESTION"):
(1) my remote object source file (CRemoteObj.cs) (dll):
using nsCRemoteObjInterface; //For IRemoteObj interface.
namespace nsCRemoteObj
{
public class CRemoteObj : System.MarshalByRefObject, IRemoteObj
{
... some stuff ...
}
}
Then, "add reference" to reference the interface assembly (CRemoteObjInterface.cs).
(2) Interface assembly (CRemoteObjInterface.cs) (dll):
using System;
namespace nsCRemoteObjInterface
{
public interface IRemoteObj : IMarshal
{
bool AuthenticateLoser(string sUserName, string sPasswd);
};
}
Nothing needs to be referenced from interface assembly.
(3) Server "CRemoteObjServer.cs" (exe):
{
[STAThread]
static void Main(string[] args)
{
//Register channel:
TcpServerChannel tcpchannel = new TcpServerChannel(8086);
ChannelServices.RegisterChannel(tcpchannel);
HttpServerChannel httpchannel = new HttpServerChannel(8085);
ChannelServices.RegisterChannel(httpchannel);
//Register TYPE:
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(nsCRemoteObj.CRemoteObj), //QUESTION 1: I still need to reference the remote object - as opposed to the interface??
"CRemoteObjURI",
WellKnownObjectMode.SingleCall //QUESTION 2: Since we'll be communicating with client via "interface", NO Singleton?
);
Console.WriteLine("CRemoteServer started and listening on tcp(8086) and http(8085).");
Console.WriteLine("Hit any key to exit.");
Console.WriteLine();
Console.ReadLine();
}
(4) Client "CRemoteObjClient.cs" (exe):
using nsCRemoteObj; //QUESTION 3: Still need to reference remote object assembly in addition to interface assembly...
using nsCRemoteObjInterface;
namespace nsCRemoteObjClient
{
class CRemoteObjClient
{
[STAThread]
static void Main(string[] args)
{
//Register channel:
ChannelServices.RegisterChannel( new HttpChannel() );
try
{
//Retrieve remote object proxy (WellKnown object - server-activated SingleCall):
IRemoteObj obj = (IRemoteObj) Activator.GetObject(
typeof(CRemoteObj),
"http://localhost:8085/CRemoteObjURI"
);
//Invoke function thru proxy:
Console.WriteLine("CRemoteObjClient: Client side invoke.");
bool bAuthStatus = false;
for(int i=0; i<3; i++)
{
bAuthStatus = obj.AuthenticateLoser("Paul", "12345");
Console.WriteLine("i={0}, bAuthStatus: {1}", i.ToString(), bAuthStatus);
}
}
catch(Exception err)
{
Console.WriteLine("Exception: {0}", err.ToString());
}
}
}
}
norm
|
|
|
|
|
Q1: Yes, you publish the object implementing your shared interface
Q2: No, you can use Singleton mode as well as SingleCall
Q3: You don't have to reference the server assembly, just the shared assembly because your client code should look something like:
try
{
IRemoteObj obj = (IRemoteObj) Activator.GetObject(
typeof(IRemoteObj),
"http://localhost:8085/CRemoteObjURI"
);
...The Type passed in is simply to tell the Activator what type of object it should marshal back and forth between server and client. Your specific object is specified by the second parameter which includes the name for that object.
Hope that makes some sense,
James
"My words but a whisper -- your deafness a SHOUT.
I may make you feel but I can't make you think." - Thick as a Brick, Jethro Tull 1972
|
|
|
|
|
Okay, it's working now, thanks a lot!
On server side:
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(nsCRemoteObj.CRemoteObj),
"CRemoteObjURI",
WellKnownObjectMode.SingleCall
);
On client side:
RemoteObj obj = (IRemoteObj) Activator.GetObject(
typeof(IRemoteObj),
"http://localhost:8085/CRemoteObjURI"
);
One more QUESTION: Alrite, we're using interface. Just why however, we can only use server-activated, and NOT client-activated?
norm
|
|
|
|
|
norm wrote:
Just why however, we can only use server-activated, and NOT client-activated?
When you're using an interface a client-activated method would require you to do:
IRemoteObj obj = new IRemoteObj(); But you can't create an instance of an interface. So in order to use a CAO it would require you to switch from using an interface to using a base class, the downside to this is that the CAO won't let you use non-default constructors. And then it gets worse... Typically your base class is declared as abstract, but if the class is abstract then you can't use the new operator again because you can't create instances of abstract classes.
As you can see, it is rather confusing. That is why I highly recommend picking up Ingo's book, because it lays out a lot of this information for you. I don't have the book in front of me, but I think a lot of chapter 3 focuses on this topic.
James
"My words but a whisper -- your deafness a SHOUT.
I may make you feel but I can't make you think." - Thick as a Brick, Jethro Tull 1972
|
|
|
|
|
|
Back in the good old VB6 there where the Shape and the Line controls, which were very useful. They seemed to disappear in the VB7 and the C#. Does any one know what happened to them?
|
|
|
|
|
dshay1 wrote:
Does any one know what happened to them?
AFAIK they disappeared by design. That is that you must paint your own line with GDI+. I don't think this is a great shift back. One may think about creating a control that behaves similar to the VB6 controls. Besides they were easy to use, they had one big caveat: They were full blown objects, with all the memory consumption.
Try searching codeproject.com for examples on GDI+. You will find how to draw a line - and four lines make a shape
Sascha
--
http://www.livingit.de
http://www.mobile-bookmarks.info
|
|
|
|
|
In the words of ME
THANK GOD
just use the GDI+ its more reliable on exact positions than those controls ever were
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
