|
Is the .Net Framework provide the methods to do the File Finding?
Thank you!
|
|
|
|
|
Check into System.IO.Directory.GetFiles().
"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
|
|
|
|
|
I am a college students at Duta Wacana Christian University, Yogyakarta,
Indonesia. I need to learn about WSDL. But, I not have a good knowledge
about it.
I have a problem. But, 1st sorry, my english so bad  .
I want to make the system like a picture that attach with this mail.
It consist of 3 library servers and 1 client computer.
1 server using FoxPro database, and the other using Oracle and SQLServer
database.
The client can search book at each library server.
The Question :
1. May be this program works?
2. If Can, can other help me? I mean u give me a hoe must i start.
Thank you very much.
|
|
|
|
|
|
Hello, I've noticed some work that Mono and dotGNU is doing to make a .NET binary run nativly on any *nix OS. However, I guess one problem that they are having is porting the Windows.Forms stuff.
Their stated reason is that Linux GUI can't handle simulating an event loop like that used in Windows. My question is what else is there? How do they get the messages and events to the program? What am I missing?
|
|
|
|
|
The linux GUI also can't appease the average computer user...but that's another point.
Anyway, the loop to which you're referring is called a message pump. It just picks messages off the queue, gives hooks a chance to process it (and alternatively throw it out or modify it), then sends it down the right chain. And technically, there aren't really events in the Win32 API. Everything comes down to messages, more aptly called notifications. (Events can come from unmanaged code, however, through the CCW from connection points)
How Mono and dotGNU plan on doing it is beyond me. The Windows messaging system is both a blessing and a curse: in many ways, it makes application coding easy since you're handling notifications and don't have to manage a huge set of callbacks. For the same reason, it can also be bad. It's easy to loose messages down the chain if notified parents aren't careful. It's also a pain to port since no other OS (I've seen) works this way.
Frankly, though, I think they could redo System.Windows.Forms.dll without using Windows messaging. Sure, it wouldn't be the assembly from the .NET Framework BCL, but it could still have the same public classes and have it signed by the same key (for which I'm sure they'd have to send it to MS for official signing). Yeah, I know that defeats the purpose, but using a messaging system would be a fundamental change in a lot of libraries!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I understand the windows message pump (I just didn't remember than name). My question is how do other operating systems do it? They use events instead? Is that through subclassing/inheritance kinda like the MFC classes try to do?
|
|
|
|
|
How would subclassing have anything to do with Windows messages? MFC is merely wrapper classes that handle those same exact messages but provide a OO way of doing it. Messages are still there, and you can still interact with them directly. If other OSes want to run the assemblies "as-is" from Windows, they're going to have to actually implement messages since the System.Windows.Forms.dll assemblies uses messages internally. That's probably why Mono et. al. are providing their own support for the BCL.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
>>
same public classes and have it signed by the same key (for which I'm sure they'd have to send it to MS for official signing). Yeah, I know that defeats the purpose...
<<
Absolutely agree that this defeats the purpose (unless MSFT is behind it).
However, I maybe wrong, but is it enough to be signed with the same MS key?
I maybe missing something, but isn't assembly hash value should match too -- If so I'm completelty confused, how would they be able to run WinForm.Control written on WinOS on Mono?...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Yeah, the hash would have to be the same. So unless Mono or dotGNU added kernel support for messaging, System.Windows.Forms.dll won't be running on either.
BTW, good signature! Now if only PHB's though like us and hired real programmers rather than el cheapo code monkeys!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
The X Window System in Linux does use a message pump if I remember correctly.
Currently Mono plans to sovle the Forms problem in 2 ways (as is typical of open source).
1) Use Wine to run the Window Forms.
2) Use a completely different graphics API. The current leaders are Gtk# and Qt#
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
Actually, on the Mono site there are provided different version. There is a type that is built using the Linux GUI and one that is going to use Wine32 to emulate Windows API. Their goal is to be completely compatible.
Personally, I wouldn't mind one that is compatible on both but does not using the standard Windows.Forms. As long as they came up with something that worked on both, I would switch 
Rocky Moore <><
|
|
|
|
|
In a recent thread on the ndoc development list (for which I contribute), we were talking about the documentation of static constructors and that got me to thinking:
In most of my work, I use the approach for creating singleton objects by makeing a private constructor, then having a static property that returns an instance from which I can call other public or internal methods or properties. The whole thing looks like this:
public class Test
{
private string text;
private static Test instance;
private static volatile object syncRoot = new Object();
private Test()
{
this.text = "Test";
}
public static Test Instance
{
get
{
if (instance == null)
lock (syncRoot)
if (instance == null)
instance = new Test();
return instance;
}
}
public string Text
{
get { return this.text; }
}
}
This seems to be the method that Microsoft uses in the .NET BCL. And it works good. I do use static constructors in some things that aren't so sensative (like wrapping some GetDevice Win32 API code).
What I'm wondering is if static constructors work just as good as the method above? I haven't been able to find any documentation that discusses this in any detail, but my first reaction is that the first method is better because monitors are used and if would be thread-safe. But does the CLR invoke static constructors in a thread-safe manner on its own?
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
acorrding to this article, the best way is thus:
sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}
as for your threading question: "What about thread-safe initialization? The Framework addresses this too. The Framework internally guarantees thread safety on static type initialization."
|
|
|
|
|
Essentially, this is the same as using a static constructor. All statics that are initialized are done so in the .cctor specialname (the static constructor). Using the above syntax is merely a shorthand. So, you've actually described the same process.
The first method I described and coded doesn't rely about a static constructor except for the synchronization object, which is only used by the Monitor and is not indicative of the singleton itself.
I appreciate your answer though. The latter part was good to know. I've always suspected based on evidence, but I've never been able to find it in the documentation which I've read from start to finish several times. (and, oh, how the ending makes me cry! :P)
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
|
I am making a photoshop-like toolbox, everything is fine except one probelm.
I have a form object as a childform of my main form.(after set the TopLevel property to false)
then the titlebar of the toolbox form would always be under the gray state?
So what's the matter with my implement?
thanks!
|
|
|
|
|
But in this realization, what if I need another form with the same demand?
I mean, I want several forms being activated at the same time(not the gray title).
The function works well without this requirement, but I just want it to act as the normal expectation.
|
|
|
|
|
What I exactly want is to show several forms as some 'toolboxes', and I don't want them to act like some dialogs that only one of them has its title bar highlighted at one point.And aslo these 'toolboxes' should act like the childs of the main form(constrained inside the bound of the main form and has a certain relative loocation in the main form).
Some child forms would do the second requirement, but the title bar thing cannot be satisfied.
|
|
|
|
|
Thanks for your reply and code
But it seems you haven't got my point...
in your realization form2 and form3 still cannot have both of their title bar highlighted at the same time.
I can set the form3.TopMost property to true and form2.TopMost property to false to bring form3 to the top level(title bar highlighted) and bring form2 drawn behind(gray title bar). That's all I can do now.
The photoshop toolbox and layer panel etc. are somekind of forms that work like 'always at top', even above the mainform.
|
|
|
|
|
thanks
Is it complex to use windows hooks to do the work?
Or only some invoke of win32 apis?
|
|
|
|
|
Has anyone ever seen an documentation/examples on building a stand alone webserver? I'm intersted in creating a FREE tiny webserver that will allow advanced webserver like functions but able to be run from a CD/DVD or Hard Drive. I know that it is possible becase there are a couple of products like this out there.
If anyone has any ideas please let me know. I could really use a sample program with code. Or at least information that will point me in the right direction.
Thanks,
Josh
|
|
|
|
|
There are several articles here on CP that deal with such issues, including reading from sockets, handling basic HTTP headers (which is relaly quite easy - it's what to do with some of them that gets difficult at times!), and serving pages. And, heck, since you're doing this in .NET, it wouldn't be hard to host ASP.NET pages. There's an entire namespace for this in .NET, and the classes are all there. There's really not much you have to do to provide basic services to ASP.NET pages (and controls, etc.).
One thing I would add (if you haven't already thought of it) is to effectively use caching, especially when run from a CD/DVD drive, as these things have very long latency times and very slow read times. It does sound like an interesting idea, though!
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Here is a table of a lot of Run-Time routines and then their mappings into the .NET World...
Link[^]
Good for those of us who have to work in both...
-Nathan
---------------------------
Hmmm... what's a signature?
|
|
|
|
|
Yummy !
..Ctrl-P
..thanks !
FOR
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
