|
Meisi wrote:
My friend says C# is a managed language and will never have good performance as vc++ has.
It depends on the type of application. VC++ will not give you much different from C# when you are building normal data driven business apps. Now, if you look and development time and debugging, you are talking a major time diference as VC++ will take longer and require far more debugging (unless you are a perfect programmer and never make typos or errors in logic  ). The current .NET works wonderful for this type of application while VC++ really lags behind.
Now, if you are developing a cpu consuming graphical game or CAD program, they C# would be very slow in its current form. In the future I would imagine we will see the line blur more.
So, basically, it is the type of application and how much time your want to spending building, debugging and maintaining.
Another aspect is if you plan to do any web work. Designing apps in C# for Windows and C# for the web allows you to share a lot of the code with little work. In VC++ it is a royal pain since you would be wrapping your C++ in COM to access it from scripting on the web site or digging ISAPI plugins for your web site which is still a pain. With C# you will be able to take most of your data and business logic and simply call it from you web application just as easy as your Windows application.
Rocky Moore <><
|
|
|
|
|
I'm trying to do a drop-down color picker, more or less using the same design as Watson39's code (here:http://www.codeproject.com/cs/miscctrl/color_picker.asp). What I find is that if you do ShowDialog() on the form, it goes Modal, and of course, you can't access the app that called it to click off the color picker and basically cancel. If you go with the Show() option, you end up losing focus on your app (it becomes "inactive") and you have a new, blank icon in your alt-tab window. I've tried setting the owner and parent of the color picker to the TopLevelControl of the calling control. No love. Anybody have any guesses on how to solve this?
thanks,
~Pb
|
|
|
|
|
With menus and combo dropdowns, you grab the mouse capture with SetCapture() when the mouse is outside your menu, and release the capture with ReleaseCapture() when the mouse is inside your menu (so that any contained controls can get mouse messages). So this would be the way to do it here. You will also want to close the popup when it recieves a WM_APPACTIVATE message where the app being activated is not your own.
I had been struggling with this with my CommandBar, but when I discovered this way, everything worked perfectly.
"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
|
|
|
|
|
Those methods don't exist on a C# Windows Form, which is what my drop-down is. I'm not quite sure what the equivelant would be, either. I'm not having any trouble capturing the events, or for that matter, getting the forms to be active appropriately. At this point, the only problem I'm still having is that when the drop-down occurs and the form is show, the main app's form becomes inactive, which should not be the case for a drop-down menu.
Thanks ~Pb
|
|
|
|
|
Patrick Bristow wrote:
Those methods don't exist on a C# Windows Form, which is what my drop-down is. I'm not quite sure what the equivelant would be, either.
Just use the APIs.
Patrick Bristow wrote:
the only problem I'm still having is that when the drop-down occurs and the form is show, the main app's form becomes inactive, which should not be the case for a drop-down menu.
Did you set the WS_EX_PALETTEWINDOW style?
"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
|
|
|
|
|
jdunlap wrote:
Did you set the WS_EX_PALETTEWINDOW style?
According to MSDN, that's only going to set the form topmost and give it a raised border. By making it a child form, I've already made it topmost. And given the design I'm using, I don't really want a raised border. Unfortunately, none of that solves the fact that the window takes the focus away from the main application, which I don't know how to stop. Really, it's just appearance, but most apps don't have this problem, and I'd like to fix it.
Thanks, ~Pb
|
|
|
|
|
|
jdunlap wrote:
Sorry, I forgot - setting the popup's parent window to the desktop window is the most important part.
Actually, I long since did that (I think I said it earlier). I set the "Owner" form. However, the "Parent" control gets mad at me when I set it to the parent window. The exception reads "Cannot add a top level control to a control." I assume that I'm only supposed to set the Owner, not the Parent (in C# terminology).
Any more guesses?  Thanks.
|
|
|
|
|
I've experimented a little and found that when you set the styles correctly for a popup in SWF, it puts your window in a "parking window". How to get around this, I don't know.
"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
|
|
|
|
|
It's that naughty WS_POPUP style bit! Remove it, and you'll be fine.  You'd think that it should be there for a popup, but that's just not true.
I remember that when I did the commandbar, I took about 3 days searching for the answer to this, and finally got it. But by today I'd forgotten it, and it wasn't obvious because I didn't explicitly remove it - I just didn't add 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
|
|
|
|
|
Now, any idea how to change that bit in C#? The library I happen to be using nicely redefines that enum in C#, but unfortunately, I don't know what function to use to set it. It's been far too long since I've had to use C++/MFC style stuff.
|
|
|
|
|
Just use the SetWindowLong API:
[DllImport("user32.dll")]
private static extern int SetWindowLong(IntPtr hWnd, int Index, int NewLong);
For the styles to take effect, you'll need to do SetWindowPos with the flags set to SWP_NOACTIVATE | SWP_NOZORDER | SWP_NOSIZE SWP_NOMOVE .
Here's the import for SetWindowPos:
[DllImport("user32.dll")]
private static extern int SetWindowPos(IntPtr hWnd, IntPtr hWndAfter,int x,int y, int cx,int cy,uint flags);
NOTE: If the popup recieves the focus at any time before the WS_POPUP style is removed, the currently focused form will not have the focus. However, once it gets the focus again after the WS_POPUP flag is removed, you can safely set focus to your popup without it losing the focus. So you have to remove that bit as early as possible in the form's creation.
"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
|
|
|
|
|
int nStyle = GetWindowLong(this.Handle, GWL_STYLE);
nStyle^=Win.User.WS_POPUP;
nStyle^=Win.User.WS_POPUPWINDOW;
SetWindowLong(Handle,GWL_STYLE,nStyle);
int nExStyle = GetWindowLong(this.Handle, GWL_EXSTYLE);
nExStyle|=WS_EX_PALETTEWINDOW;
SetWindowLong(Handle,GWL_EXSTYLE,nExStyle);
"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
|
|
|
|
|
"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
|
|
|
|
|
You just remove the WS_POPUP style. (BTW, you probably don't need to remove the WS_POPUPWINDOW style.)
"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 use it as:
Form fPom=new Form();
fPom.ControlBox=false;
fPom.ShowInTaskbar=false;
fPom.StartPosition=FormStartPosition.Manual;
fPom.FormBorderStyle=FormBorderStyle.FixedToolWindow;
fPom.Deactivate += new EventHandler(this.fPom_Close);
fPom.Location ...
I open this form by Show() method and close it in Deactivate event (other events doesn't work good)
Hi,
AW
|
|
|
|
|
A.Wegierski wrote:
I open this form by Show() method and close it in Deactivate event (other events doesn't work good)
This works in some cases, but suppose it's a menu, and has submenus? When the submenu recieves focus, the original menu disappears.
"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
|
|
|
|
|
Hi,
I am writing a multi-threaded program that involves concurrent access of ArrayList objects. Some threads need to read the list, while others need to modify it. Both operations must NOT occur at the same time, and none of the thread need read & write access. they are either reader / writer. actually, in my case, there's multi-reader and a single writer. How can i manage the access with SyncRoot or any other synchronization API in C#?
MSDN disnt provide much info...
Thanks.
|
|
|
|
|
viperxp wrote:
MSDN disnt provide much info...
Static members are often easily overlooked (Intellisense is partially to blame). Have a look at the ArrayList.Syncronized() that returns a thread safe wrapper for the arraylist that you passed to the method. I have never needed to use it, but that is how I understand it.
Hope this helps
<a TITLE="See my user info" href=http:
|
|
|
|
|
You may also want to look into locking the SyncRoot instance property.
|
|
|
|
|
I ahve looked at both the Synchronized() and the SyncRoot property in MSDN, but i dunno how to use them (to solve my problem) ... maybe can someone provide some hints on how can i use them to address my prob?
|
|
|
|
|
viperxp wrote:
I ahve looked at both the Synchronized()
The Synchronized() method returns an instance of an ArrayList which takes care not to let only one operation run at a time.
The SyncRoot property returns an object which you can use to do your own locking (by using the lock keyword for instance).
ArrayList syncList = ArrayList.Synchronized(theList);
...
And a second demo:
ArrayList theList = ...;
...
lock(theList.SyncRoot)
{
}I prefer using lock, because it makes it very obvious that the code within is protected instead of trying to trace your steps through code to see whether you forgot to create the Synchronized wrapper.
The only advantage I can think of using the synchronized wrapper would be if you were performing lots of operations in a row where it didn't matter if other threads accessed the list in between those operations.
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
OK, let theList be the persistent copy (the one containing data that my app uses). is syncList an identical copy of theList, or just another reference to theList?
in my program, the threads will either read from or write to theList. Read & write operations will be mutually exclusive i.e. they cannot happen at the same time. when theList is being modified all reader threads must wait till the write is complete b4 they can read. Similar, the thread that modifies theList must wait till there's no read ops b4 changing theList.
There's multiple readers, but only 1 writer thread.
How can i apply the Sychronized(), lock(), and SyncRoot in my context?
I am quite new to C#, so I may not know certain things that u assumed that I should know. Can any1 provide me with a more detailed example, or perhaps point me to a more elaborative resource? thanks a bunch.
|
|
|
|
|
viperxp wrote:
is syncList an identical copy of theList, or just another reference to theList?
It is wrapper around theList, which internally contains a reference to it.
viperxp wrote:
How can i apply the Sychronized(), lock(), and SyncRoot in my context?
With Synchronized() you don't have to do anything but ensure that you do all of your reading and writing with syncList.
From the documentation on the "lock statement" (since I couldn't think of the correct wording, but slightly modified):The lock keyword marks a block [of code] as a critical section by obtaining the mutual-exclusion lock for a given object, executing [the code], and then releasing the lock. You use it by passing in a reference to an object which will serve as the 'key' to entering into the lock.
In this case, the 'key' to the ArrayList is returned by the SyncRoot property.
HTH,
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
First of all,
Thanks for prompt reply.
James T. Johnson wrote:
With Synchronized() you don't have to do anything but ensure that you do all of your reading and writing with syncList.
Are u saying that whenever I need to access (be it read / write) theList, I just get the enclose the code block in a lock(syncList.SyncRoot), no matter where the read / write operation lies... in my case, they are in different classes.
From what u wrote, it seems that i dont have to do any checks, i.e. is there any other threads accessing tthe list or not etc b4 commencing my "I/O" operations... is my interpretation correct?
can i put it in this way....
syncList.SyncRoot provides a "safe" reference to theList. whenever any code within lock(syncList.SyncRoot) is running, all other code accessing theList - most probably thru the syncList.SyncRoot reference, regardless of whether it's in a lock() block or not, will have to wait till the "active" lock() block completes?
how about deadlock and "starvation" problems...? e.g. when a thread terminated prematurely, will the lock be released? if not, wut can i do prevent this prob?
Thanks again, yur replies helps a great deal 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
