|
Thanks for this clear and concise explanation. Sometimes one doesn't know what one doesn't know - if you know what I mean! 5 from me. 
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
Thanks for the reply.
I'm not using the task manager to get the memory stats in my app, i'm using GetProcessMemoryInfo() from the Win32 API wich is the same i guess.
The real thing is: Try this minimize-freemem thing with WinRAR and Task Manager. WinRAR is not .NET (.NOT for me  ). So, i think .NET is not the issue here. This also applies to Win32 and all subsequent wrappers.
Anyway, for my app i'm also using native Win32. Don't know why your reply is strictly related to .NET. "Windows Forms" is not .NET. WinForms is present also in COM programming (VB6 for example) and MFC so i guess i'm not in the wrong forum (unless this forum is specific for the System.Windows.Forms.dll .NET module).
.NET or not, my question has been answered anyway ("...What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using...").
Thank u very much.
-- Modified Monday, August 16, 2010 3:12 AM
|
|
|
|
|
Heinz_ wrote: So, i think .NET is not the issue here.
Actually, .NET increases this little "problem". Your app may be very small and not use any data at all and still take up 20MB of memory when started. When you minimize/restore the window, the memory "usage" may drop to 500K, or whatever...
|
|
|
|
|
hi i am using c# windowform 2005
i am trying to explore and learn if window form can manipulate mouse and keyboard movement e.g like a macro mouse to point 1,7 and etc
and what classes they use if it is possible
|
|
|
|
|
yes it is possible.
AFAIK you need P/Invoke for mouse automation, see functions SendInput and SetCursorPos in user32.dll; for keyboard automation the .NET System.Windows.Forms.SendKeys class could be sufficient.
For all of them, you must make sure you are talking to the right window, which needs to have focus; so you will probably need even more P/Invoke and use functions GetForegroundWindow, SetForegroundWindow, GetWindowText, and maybe more.
Warnings:
1. you probably need to include some delays, say Thread.Sleep(100), so the target application can react to your automation inputs (which otherwise would come much faster than a human user would provide them);
2. whatever you do it will not be absolutely safe. For one, there could still be a user typing/mousing around; second, target apps may suddenly throw unexpected stuff at you, maybe a dialog telling you the disk got full, the network connection was lost, etc.
|
|
|
|
|
My company has a winform application with hundreds of forms. The application is close to be released and management now want us to add application level security in it. So basically things like a user X in role Y can do certain things but should not be able to do other things. We cannot reply on the fact that all our clients will have windows domain.
My initial thought about its design is to have some kind of mapping in terms of UI elements in different forms and then make these UI elements read-only based on permissions. Just wondering if there are any patterns of implementing it and if anyone can point me to links for it? I have looked at Security Application Block in Micorosoft Enterprise Library and seem like it can be used for authenticating the users but its probably problematic if you are not on Active Directory (correct me if I am worng here)?
|
|
|
|
|
imak wrote: The application is close to be released and management now want us to add application level security in it
What an excellent planning and design system you have. This is so common it hurts (it is now going to bite you guys).
From a couple of decades of practical experience!
. Internalise you security, manage your authorisation in your application by mapping UI elements to roles.
. We use an AEDX field on a function (UI element) that allows a fine grain control
. Base your authentication on Active Directories, once they log on they are authenticated, then look up your internal authorisation tables.
. Create a base form that all your dialog/forms can inherit that will do your user validation.
We have a main menu and 95% of apps (we have about 15) only require security applied to this level (ie this user group can have the Customer function but has no AEDX rights on the form, therefore it is read only)
Adding security to a major app is not a trivial excercise and testing is a stone bitch! Good luck
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
How are the security roles going to be described to you? Usually in situations like this the business user will describe the security in terms of a business process rather than individial pieces of data. Something like "the accounting role can process invoices" rather than "the accounting role can update the following fields...". If your app is designed along similar business process flows, then the security can probably be applied to a few buttons and menu items or at the form level rather than lots of individual data controls. Mapping each and every UI element to a permission scheme can be terrible for performance. Since this is something that you distribute to multiple clients you also need to decide about how the roles will be managed unless you intend to force the same scheme on all of your customers.
|
|
|
|
|
this is the right time to add application level security. Never think about such things when you start writing your app. Always add security related things in a hurry short before release date - and of course don't waste time testing it. 
|
|
|
|
|
Hello imak,
In one of my application I have implemented Application settings same as you want to right now.
I developed Security Level for each type of user type. Admin can add so for each form/task in the application. When the logged user logs in, reading these set settings user can access or cannot access based on the security settings. For example, you have Customer form :
Customer
Add 0, 1, 2
Edit 0, 2
Delete 0
User Type with Roles (0- Admin, 1-Operator, 2-Receptionist] are set as 0, 1, 2... and so are to the tasks of Custoemr form. So you see
Add can be performed by Admin, Operator & Receptionist;
Edit can be performed by Admin & Receptionist;
Delete can be performed only by Admin
The same if you don't want to do task wise and only form wise, you can do that to by just setting for Customer form and not tasks of the form. So all tasks will be set by all those users.
Hope this helps.
NOTE: Vote if this helps.
Thanks & Regards,
|
|
|
|
|
Hi code project members,
as the title says i want to achieve the following mockup (link to my skydrive, sfw):
FixedToolWindow_WithNoCloseButtonMockup[^]
I tried lots of possible solutions, like removing the menuitem through interop, setting Form.ControlBox to false, but either the close button is still visible, or the formborderstyle changes to one with round egdes.
I definitely would like to create one with the nice rectangular fixedtoolwindow style without all the os provided buttons.
If someone could help me out here, because im kind of lost here.
Thanks in advance.
Balkoth.
modified on Tuesday, August 3, 2010 12:44 PM, to fix the new window link
|
|
|
|
|
AFAIK the only ones you can get right away are shown here[^]. If you need something else, you'll have to do all the painting, i.e. client AND non-client parts.
|
|
|
|
|
Thanks for your help, i was hoping that there was something which i haven't yet discovered to do the magic trick.
|
|
|
|
|
Hi members.
This is the preview, for what i was trying to achieve the effect.
Thanks for your attention.
Greets Balkoth
|
|
|
|
|
Hi all,
I have a tabcontrol with a lot of tabs which may be added and removed dynamically. I'm using a multiline tab control due to the amount of tabs involved, and I would like to simple be able to add a tab to either the top or bottom row of tabs programatically. Is that at all possible?
Thanks..
|
|
|
|
|
ruanr wrote: Is that at all possible?
Yup. Did you run into a non-working insert method? If yes, then there's a workaround[^].
IntPtr h = tabControl.Handle;
tabControl.TabPages.Insert(0, "test");
Alternatively, you could move pages around as shown below 
var tabControl = new TabControl();
tabControl.Parent = this;
tabControl.Dock = DockStyle.Fill;
tabControl.Multiline = true;
Controls.Add(tabControl);
tabControl.TabPages.Add("bla");
tabControl.TabPages.Add("bla2");
tabControl.TabPages.Add("bla3");
var temp = tabControl.TabPages[1];
tabControl.TabPages[1] = tabControl.TabPages[0];
tabControl.TabPages[0] = temp;
I are Troll 
|
|
|
|
|
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years.
I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web.
It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well.
Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
BobishKindaGuy wrote: probably a quarter million lines of code, that has evolved for well over 10 year
Converting this to a browser based application is not going to be easy.
It could take ages.....
There are a few plugins [^] that display winforms within browsers and you could consider them.
|
|
|
|
|
Thanks Abhinav.
The plugins reference you cited has a posted date of 2003, so I only spent a moment looking at it, since so many current ideas are very different from what was available at that time.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
modified on Wednesday, July 21, 2010 1:43 PM
|
|
|
|
|
I'm a winforms person by preference and have avoided working with the web, thankfully. However we have just made the decision to move to web delivered UI for all new development. To reverse a 10yo, still evolving app, thats going to be tough for a 1 man show.
A lot would depend on your customers, do you work in a company or do you sell the app as a commercial product? Who is going to foot the bill?
Mind you a total rebuild improves any application. I know any app I built 10 years ago would benifit from it.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks for your thoughts.
I guess a core of basic necessary functions would have to go together on a web UI, and leave less-used functionality as a desktop app. They could use RDC to go in and change some of that. (It's a commercial product.)
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
It was the same with me. I avoided web development for a good long time. I'm only just now really getting into it with a new application I'm developing. It's cool - but it ain't the same as WinForms development - not by a long shot. You had better be ready to edit HTML even with .Net 3.5 or 4.0 to get your forms working. It ain't WYSIWYG - and you have to think completely different. Instead of event-driven, you're talking page lifecycle. Smokes the brain for awhile until you get it.
-Max
|
|
|
|
|
Thanks, Max,
Yeah, I can see that some of the friends suggesting an approach such as is provided with visualwebgui would take some of the pain out of the events versus page lifecycle paradigm. Either way, it's a total change of thinking, which all comes from the issue of sending bytes along a wire asynchrounously instead of counting on resources (code) being instantly available to "answer" some event.
Actually, I think the whole asynch paradigm is what we will all need to do within the next few years. It might be good practice to use delegates for everything within some sub-project just to get used to it. In fact, (philosophising here) I believe asynch thinking is probably more real-world than what we do now, which is like tugging a string and expecting the other end to move. It's like you have a message, so you put it in a bottle, throw it in the ocean, and then you need 100 people to watch the beach for "if and when" an answer comes back in a bottle. The real world works like that - when you order some product by phone or on a website, it's only when the product arrives at your door that you know you have it. Some truck 1,000 miles away brought it, but you weren't pulling the truck along a wire to make it arrive. Things are inherently disconnected in the real world. The days of quickbasic are gone ha ha ha.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
I'd say that the best way would be to avoid rewriting the entire application. I imagine that your application consists of multiple, smaller modules that interact?
How about adding functionality that allows interaction over the web, without ditching the desktop-application? What starts with writing a webpage to retrieve/modify configuration-settings could very well grow into a separate interface over time
I are Troll
|
|
|
|
|
Right, continue the evolution.
Any ideas what may be the best technologies to use? This WebMatrix looks promising.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
