Just another one of these circular Progress-UCs, which recently seem "all the rage" ...
What's different with this one?
- it's really small (only about 80 Lines of Code), so no need to put this into a compiled OCX
- it's entirely GDI-based (just for fun, I've tried to avoid anything "Cairo or GDIPlus")
- it uses a single ChangeSettings-MethodCall ...instead having to set (or implement) a bunch of behaviour-Properties
I guess you mean the "single Settings-Method" (instead of using, or implementing a bunch of Properties explicitely)?
Well, if you're more of a "visual guy" who has to see things beforehand (already in the Form-Designer),
then yes, it's less comfortable this way...
On the other hand, this "single Method, setting the most important Props via code"
has the advantage, that it "just works" (but of course later - at RunTime then).
E.g. with your "reduced version" of Leandros code, this one was not reacting to Property-changes in the Form-Designer as it should (it "forgot" settings at runtime).
There was also some Refresh- and DPI-awareness problems on my machine, where I'm running my IDE with "Win10, extended DPI-awareness-settings".
Originally Posted by couttsj
Question though, what exactly is "HitTest" used for?
See..., now - after some code-reduction, you've even found that little critter
(which was BTW also already contained in Leandros Code).
This stuff is necessary on any UC, where you ensured "full transparency".
If you comment-out the line (which formerly "satisfied the HitTest positively, for the whole Ctl-area"),
then you will have "full click-through" behaviour on the Control.
A more elaborate implementation within this HitTest-Eventhandler could ensure, that you really spare out unwanted parts of the Control-area
(making only them "click-through", as e.g. the "corner-parts" which lie outside the circular-area in case of a RoundButton-control).
will this multithread running ? i don't know the terms, so the progress will keep running while we doing looping , etc ?
You have that multi-threading-stuff entirely backwards (IMO)...
From what you wrote above, you apparently want:
- to visualize the Progress-Info in a PopUp-Window or something, which runs on its own thread
- whilst running your "heavy-processing"-loop inside your MainThread
But that's not "how it's done"..., because normally the Main-Thread is "for GUI-stuff only" (not stressed with any heavy work):
- so instead it's the "heavy-processing"(non-GUI)-loop which should be run on its own thread, ...
- who then has to report Progress-info from the worker-thread -> back into the Main-Thread, ...
- and once that Progress-info has arrived back in the (mostly idling) MainThread, ...
- you will simply update your GUI (on the Controls which are related to that incoming Event-Info)
See..., now - after some code-reduction, you've even found that little critter
(which was BTW also already contained in Leandros Code).
This stuff is necessary on any UC, where you ensured "full transparency".
If you comment-out the line (which formerly "satisfied the HitTest positively, for the whole Ctl-area"),
then you will have "full click-through" behaviour on the Control.
A more elaborate implementation within this HitTest-Eventhandler could ensure, that you really spare out unwanted parts of the Control-area
(making only them "click-through", as e.g. the "corner-parts" which lie outside the circular-area in case of a RoundButton-control).
Olaf
The only reason I ask is that the Microsoft archive says "It is important to note that the HitTest event occurs only on a Windowless UserControl with the BackStyle property set to Transparent", and I noticed that on your control the BackStyle property was set to "Opaque".
...the Microsoft archive says "It is important to note that the HitTest event occurs only on a Windowless UserControl with the BackStyle property set to Transparent",
and I noticed that on your control the BackStyle property was set to "Opaque".
Well, the FormDesigners Property-Grid is (as said) not the primary thing I work with (when it comes to Controls).
I prefer to set Control-Properties "in code" - leaving the Property-Grids of most Controls alone, and at their default-settings.
So the BackStyle-Prop you've checked was adjusted by me in UserControl_Initialize (to transparent behaviour)...
along with some other Inits via Code, which are all needed to ensure proper Windowless-mode
(to not having to "fumble around, trying to remember the right Prop-Settings" in case I open a new Project, to start working on the next Windowless-UC-project)
Code:
Private Sub UserControl_Initialize()
ClipBehavior = 0: BackStyle = 0: FillStyle = 1: ScaleMode = vbPixels '<- ensure transparent behaviour
'...
End Sub
Olaf;
I think I understand now. Rather than adjusting the default properties of the control, you adjust them via code. Because the control is Windowless and Backstyle = 0, setting HitResult = vbHitResultHit causes the control to react to a click event. Remove it, and it does not react to a click event.
Thank you for the explanation. I like your code better than mine. It is much slimmer and I presume less resource hungry.
Olaf;
When checking the response time, the call to change the Value of the User Control measured near zero, whereas the actual Paint routine took 15 to 31 ms. That must mean that the call returns immediately and the Paint routine occurs in the background. That was measured when operating in the IDE. Strangely enough, when measured in the compiled program, the Paint routine measured 47 - 63 ms.
Am I correct in assuming that the painting would have marginal impact on the response of the main program?
@ couttsJ I don't know if this applies to you but when I have seen these strange differences in timing, it is usually that the IDE is run elevated but the compiled is not.
@ couttsJ I don't know if this applies to you but when I have seen these strange differences in timing, it is usually that the IDE is run elevated but the compiled is not.
I'm afraid I don't know. Perhaps Olaf or Dil will chime in. What I do know is that if you want the ultimate speed for something then it must be compiled and (even though we frown against it) elevated.
Here is Olaf's Radial Progress Bar as an OCX. You will notice that RadProg.OCX is less than half the size of CircProg.OCX. As far as I can tell, the execution speed is about the same.
The instructions for use are virtually the same. Compile and save it in it's working directory as RadProg.ocx. Before utilizing it, copy it to the \Windows\SysWow64\ directory (\windows\System32\ on 32 bit systems). This will allow you to access it from anywhere on the disk, and it is where all the other OCX files are. An OCX is accessed via it's CLSID. Load the TestOCX.vbp program. Now add the RadProg.OCX component. To add this OCX to your VB Components, use the Browse button to select the RadProg.OCX from the \Windows\Syswow64\ directory. This process will register the OCX and a new icon should appear in the Components window. Double Click it to add the default UC to frmTest. You can make changes to the normal default properties such as size, but other changes such as color are made with code in the form load event. Change the name to RPB1 and save the result. Now run the program. Click and hold the right Scroll arrow, and the new radial scroll bar should advance from 0% to 100%.
The first time I went to use the new Radial Progress Bar in a real world situation, I ran into a problem. I could not bring the Progress Bar into the foreground on a busy application with a large Ink Edit control. But Olaf had the right idea by moving it into a windowed control such as a Frame or Picture Box.
Attached is the same User Control placed inside a borderless Frame. When the start button is depressed, the Frame is made visible and the Timer is started. This sample has been organized such that the progress bar is not updated if the incremented value does not exceed the currently displayed percent.
Just another one of these circular Progress-UCs, which recently seem "all the rage" ...
What's different with this one?
- it's really small (only about 80 Lines of Code), so no need to put this into a compiled OCX
- it's entirely GDI-based (just for fun, I've tried to avoid anything "Cairo or GDIPlus")
- it uses a single ChangeSettings-MethodCall ...instead having to set (or implement) a bunch of behaviour-Properties
... .. .
Have fun,
Olaf
Superb. I just loved it. I happened to see this very very beautiful, eye-catching control of yours, Olaf, when I was searching for a Radial Slider in vb6.
I could not get a Radial Slider for VB6 even after searching hard. Was wondering whether you can get the time to create one, since I believe that it will be similar to your circular progress bar control except that the counter will change only when I drag a needle around (clockwise or anticlockwise). I would be much grateful if at all you can make one please (for an example of what I am looking for, you can kindly see this page - https://help.syncfusion.com/windowsf...etting-started)
There are many such complex beautiful interface, animation effects can be achieved using the web, very simple. Webbrowser control to load HTM, JS, can be used in conjunction with a try.
I wrote one already - included in this CodeBank-Project here: https://www.vbforums.com/showthread....CoreAudio-Demo
(still RC5-based, but the Demo should work as well, when you switch the Project-reference to RC6).
There are many such complex beautiful interface, animation effects can be achieved using the web, very simple. Webbrowser control to load HTM, JS, can be used in conjunction with a try.
I do get what you are saying. We can do very many sorts of beautiful things easily using javascript, html5, css and what not (with all those readymade free js libraries available on the net). But, I was just looking for an extended full-fledged vb6 example to get the hang of using Olaf's web control*
(*) I have made use of our dear Olaf's wonderful wonderful wonderful WebEvents vb6 example (https://www.vbforums.com/showthread....ent-connectors) already (in 2020, for the first time). No words of praise are enough for Olaf. But, I did not get time to use its capabilities extensively. Also, while using it in one of my projects, suddenly some error will pop up (I don't exactly remember the error message now since I was trying it around 1.25 years back). But, it must have been surely some mistake in my coding only. So, what I will do now, based on your motivating words (serving as a catalyst), is to take time to explore more of Olaf's classes and their capabilities (which require no references, components, etc. to display web pages inside VB6) in Win10 system.
I have a Win7 laptop too, which I don't use. So, when time permits, I will switch on and test out my executables in that too and report back. If there are any doubts, I shall come back to you, Olaf, for your ever-present guidance and help.
By the way, Olaf, compared to the 3 lightweight simple classes (which not only display web pages but handle events on them too with ease) in your WebEvents examples, what all added benefits I would get by using WebKitCairo? Extensive JavaScript support, I suppose. Sorry that I am not finding time to try it out myself. Because of such lack of time only, I am requesting you to list out the advantages so that it will be helpful for me in future when I get time to try out WebKitCairo. Or, if there is a tutorial, kindly let me know its link. I will read the same. I have so far found the following tutorials only - RC5cairoTutorial.zip, RC5formsTutorial.zip, RC5WidgetsTutorials.zip and CairoTutorial-master.zip. Are there any other tutorials? If so, kindly let me know all the links.