Control Panel -> Security Center
I really like the components/controls which are used to show if a firewall or the Automatic Updates are enabled.
Are these reusable controls in C# or Delphi?
These components are internal to Windows and are not available to be used outside of the operating system (and are written in C++).
These are not reusable. They are built into Windows so you would need to either make your own custom version of these controls or find someone who already has if you want to mimic their look.
If you post a new question (or just add to this one) asking how to make something like it, and state what language/environment you would like to do it in, I'm sure we could point you in the right direction.
Yes, they are reusable (of course, as they are in ring 3 !!!)
Simply load them from ATL.DLL (C code had been posted several years ago on BBS...)
Some wrong and newbie answers are unbelievable...
Related
I've been trying to search for ways to change the way windows controls look.
For instance change the OpenFileDialog UI at a windows level, or completely turn the file copy/delete/move dialog into something else, like a series of disks or a bucket filling up with liquid.
Looking around i found that i could write a com app that could be used instead of the default windows ones. But i have no idea where or how to start with these, or even how i could see what i would have to implement to achieve this, nor how i would be able to tell windows to use my custom ones instead of the default ones.
Have tried looking in the microsoft documentation, and i'm 99% sure i'm either unable to search for what i need or it's undocumented.
I know there are some apps from Stardock that could do this where i could just make the graphics, but where's the fun in that?
Anybody able to point me in the right direction?
Interested only in being able to achieve this for windows 10.
You could in theory write your own implementations of IFileOpenDialog and IFileSaveDialog and overwrite the Windows registrations in HKCR\CLSID. This might not affect older applications that use the older open/save common dialogs.
There is also CLSID_ProgressDialog and some progress related interfaces you could take over but I don't know if Explorer actually uses these or its own custom version.
This could obviously break your system so you really have to know what you are doing if you go down this path.
While you are developing this you could choose to selectivity inject into a limited set of processes and hook CoCreateInstance instead.
Changes to existing dialogs (adding/moving/hiding controls and images) can be done with Resource Hacker. This was pretty easy in the 90's but it is more problematic these days because some files are protected and Windows updates are more common.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking for a tool for automated testing. I will use scripting for testing, rather than just automating, which means that it can't just send some key-presses. It needs to examine the app's window to see if it was updated correctly. The cheaper the better, with no downside limit on cost. ;-)
I need a real language, with functions, variables, loops, branching, etc., and the apps are developed in Delphi.
I need to be able to focus controls*, wait for windows to appear, search for controls/windows, send keyboard input and check that various windows/controls have changed state (e.g a button is now disabled, a text box contains the correct text, a dialog box opens, etc.).
I used to use AutoIt a few years ago and am now coming back to scripting. I wondered if there has been any new development while I was gone.
Any suggestions?
* I do not want to move the cursor to absolute coordinates in case the app's layout changes. This quote from Wikipedia explains why:
Regression testing becomes a problem with GUIs as well. This is because the GUI may change significantly across versions of the application, even though the underlying application may not. A test designed to follow a certain path through the GUI may not be able to follow that path since a button, menu item, or dialog may have changed location or appearance.
I believe you just described TestComplete by SmartBear Software.
Autoit does everything you listed. I use it for the same porpoises all the time. Also, Delphi is good in the sense that uses standard windows controls which makes it very easy to hook into.
I've had some success with sikuli, which has the advantage of being python (jython) code. It is built on top of OpenCV, and uses a full image processing engine to pattern match parts of the screen. It also contains editors and functions for screenshots, waiting on changes, as well as keystroke and mouse injection.
Something different from my other answer: PyWinAuto
It has full scripting (because it's Python), it uses control names instead of X, Y coordinates, it waits for windows and you can send keypresses. And it's free.
The downsides should be obvious :)
To automate a delphi application main problem i found was that the any testing tools (QTP with delphi addon , Test Complete , Testanywhere, autoit, sikuli) they all dont detect any Tlabels and Tlist and and other components, which for an application build in delphi forms a prominent part of the UI. Even to do func based testing we need to ultimately examine a component in the front end to see whether a func is giving right out. Even to right a script to automate we need to first be able to detect and add the object to the repository.
We have an application in which we have heavy dependency on a lot of third party components. I have tried to check feasibility with almost all the tools available in market.
The top two tools in market were of no use.
QTP with Delphi addon is of no use even in there website they have openly mentioned it wont support many classes build in delphi.
TestComplete its better than QTP where in it detects many components menu components and if i remember correctly grid etc.
Then after few googling i found
TestAnywhere which was certainly better in detecting the thirdparty build components. Only problem i found with this was that it was not detecting Tlabel classes and some components dont remember which.
When i speak of detecting components it may be partial or fully ie some tools were able to detect that there is a component at XY co-ordinates but failed to get the component classes or details (like components property name etc) without which it was difficult in automating and writing a script.
Rest all was more or less combination or subset of these above there.
Still Searching !!!!!!!!!!!
With TestComplete, if you compile your app as an open app - i.e. include their libs, it makes your app super inspectable. Great for testing, probably not best for security. Test complete was the best, it is just TOOOO expensive for my budget.
The scripting in it is great, the understanding of Delphi is great. The pricetag is just not great, especially if you are trying to get traction for GUI testing within an org, like it sounds like you are.
There are many applications for Windows these days that don't use native windows controls, don't have standard window frames and generally look different. What are some recommended techniques for creating such interfaces?
There are good reasons not to. Like that you will most likely not do a better job than Windows does. (Maybe it will look better (in your opinion), but will it behave?). Or that it's not what most users expect. Or that it will look like s**** on Windows 2011.
That said, it's not hard. You simply handle the WM_NC* events like WM_NCPAINT or WM_NCHITTEST. NC stands for Non Client (window area). And of course, there is a trick on Vista/Win7 (you have to announce it to the DWM).
From an implementation aspect, you could employ WPF (Windows Presentation Foundation) assuming you code for .NET :) It has pretty bunch of skinnable controls, that may look like native and may not.
From a design aspect, if your interface isn't going to follow documented standards (like the Windows UI guidelines), it has to be intuitive. I think the new generation of Windows applications will go through a growing phase in a manner similar to the early days of the Web. After a time, some standards or common themes will evolve.
Can you give us some sample applications? Some apps that don't use native windows controls use cross-platform GUI libraries, like Qt for C++ or Tkinker. These maintain the same look across different platforms.
I wouldn't really recommend making your user interface different deliberately. You don't stand to gain much. Your controls are almost always going to be buggier than native controls, and you are requiring the user to learn something new. Now, if you're controls add a large enough value to be worth the users' time it can be okay. But making them get used to different looking buttons is rarely worth it.
I`m not sure if this answer your question.
You can use third party skinning controls like from Infragistics, or SkinSoft for example.
But like Bubba said I`d recommend going for WPF.
Model-View-Controller! It's as valuable here as in web apps or anywhere else. Be sure to keep the part of your program that generates the custom UI separate from the part of your program that flashes the BIOS.
I know this question is 10 years old but none of the answers mention using an option in visual studio, dont know if it existed at the time.
Theres an option to remove the border of the window in visual studio (called borderStyle). Thats the easiest way to do it, using C#. After removing the border, all you have to do is create a new interface. If you're looking to do it in C++, i think you need to use DWM. I will let an example i found here.
https://github.com/melak47/BorderlessWindow
Another example (maybe without DWM? didnt test):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b98c4c06-9581-44d3-8e5a-4adb2316e653/win32-about-styles-how-can-i-do-a-borderless-window?forum=vclanguage
There is a lot of people disencouraging to do it in this thread but there's no reason to not do it, if you know what you're doing your application can look great.
Is there a way to apply consistent visual appearance for multiple Windows Forms applications? So that the same color scheme is used, etc? Or you have to do it manually?
(I apologize for this question, but I have googled it without any real answer - a couple of pointers in the right direction or a few links would be enough. I have also searched here, so if it is a repost please close it)
I have used components from Developer Express to do this. Take a look at: DevExpress .NET Windows Forms Skinning Library
There are probably other resources out there for this, depending upon your needs...
If you want a consistent appearance that is different from the standard Windows appearance, then you have to do it by hand - possibly with the assistence of some sort of 3rd party skinning library.
I want to control the mouse pointer with my application and be able to interact with other programs using my program,
For example I want my application to be able to click on a button on another application
How should I go about solving this problem?
(Any programming language would work, also if you have any suggestion please let me know)
Afterthoughts:
I want to do it in windows operating system and want to test my GUI to see if it works in different scenarios. Any language would work for me since this is not part of the final product but I prefer one of these languages (Python, Java, C# or MATLAB)
Thanks
There are many ways of doing this, and you didn't mention any details of your application (system, target goal, etc...).
If your goal is menial automation, I'd recommend whipping together a quick AutoIt script on Windows. http://www.autoitscript.com/autoit3/index.shtml
If this isn't what you're looking for, please give more details.
Okay, this one is really operating system and windowing specific. But the phrase you're looking for is "mouse grabbing".
As #Mitch suggests, unless you've got a really good reason — like maybe a GUI testing app? — then grabbing the mouse and messing with it in that way is very bad form.