First, polymorphism. When it was new (early in C++), it was the new toy everyone overused. I had programmers insist that every function should be virtual "just in case". It was a bad idea. Not that polymorphism was bad, but the "just in case" overuse when there was no plan to use polymorphism. You can do quite a lot without it.
The classic classroom example is shapes. A base class, called shape, is itself a shape but has no shape. If used it would represent, at best, an invisible shape at some location. There would then be classes fashioned for triangles, circles, rectangles and various shapes one might want to draw, all derived from shape. Most particularly, in this classroom example, the draw function would be virtual. In a textbook fashion, the destructor of shape would be made virtual so the object destruction was complete (considered really bad to skip that step, but there are exceptions).
The point here is that a container could be fashioned just to hold shapes. Imagine the difficulty of creating a container that can old all of the shape types. You'd be relegated to void pointers an casting, known to be a source of bugs. Instead, the container "knows" only the base type. It should store objects via pointer (suspicious in the early days), because an array of shape objects could not be coaxed into morphing into triangles, circles or the other derived types. Now, however, a draw function could merely loop through this container of shapes, and the virtual draw function of each shape would "automatically" choose the particular function in the derived object to draw the specific shape originally created. That is, a shape pointer would hold a "new triangle" or "new rectangle", but would only "know" those by the base class shape.
That is the classic example, but I now show you a questionable yet common use case. In a rendering engine (games, CAD, whatever), one must contend with the various API types for drawing 3D graphics (OpenGL, DirectX, Vulkan, Metal, etc). One could fashion a base class renderer which doesn't care the specifics of the rendering API. It represents the common interface for drawing, configuring, etc. It would allow you to write a 3D graphics application which could, then, choose the rendering API at runtime. Indeed, many do this. It is questionable because in reality such applications are written specifically for an API by design (they're quite different from each other). However, there are some rendering engines which design their rendering class as a virtual base class, with derived specifics for each API they support, and the user can select which at runtime - usually at startup of the application. It is faster, however, to substitute the rendering API by FILES in the build, rather than by polymorphism. There is a small but measurable performance penalty for virtual function calls.
With that questionable example, however, I do hasten to point out that when appropriate based on what you are modelling, polymorphism is a power mechanism.
Now to your VB inquiry. Most of the good frameworks operate in a way that you've indicated. If you know the C level Windows API, you know it is a hassle to figure out which button fired a command. In most modern frameworks you can provide some kind of "pointer to function" paradigm, often using the std::bind library. Basically, you get "call this function if this button is clicked" convenience. This is true of WxWidgets and Qt, both of which I can recommend, though I'm partial to WxWidgets myself.
So, since your question ended with "...this the same for c gui?" - I'd say, C++ GUI frameworks, not C. The Microsoft MFC framework, however, is no longer a good example. Qt & WxWidgets allow you to target MAC, Windows a Linux from a single body of code. MFC only targets Windows, and is still very much like the C API (they called it a thin wrapper, and it never was much leverage).
GUI's operate on messages. These are merely numeric packages of data, which indicate the nature of the message and some parameters for it, like the mouse location or the Window ID. Modern interface techniques allow you to define responses to OS messages from the GUI with a "std::bind" style approach, that is an encapsulation of a pointer to a function. There will be a declarative section at the initialization of a window where the programmer lists all of the messages of interest and the functions to be called when they fire. The GUI framework unpacks the parameters into a comfortable representation (they are typically packed into two variables one must "bit fiddle" into something meaningful, in C). This means if you want the LButtonDown message from the mouse (anywhere on a custom display, for example), what you get isn't LPARAM and WPARAM that you must crack into pieces, you get the X, Y location of the mouse at the time the button was pressed (or released), routed to whatever object (usually a window, but not always) that should receive the message. That sounds trivial, but compared to what must be done in MFC or a C style application for Windows, it is wonderfully effective and simple.
Also, as part of your question, you bring up "MsgBox("Hello")", and there, too, the frameworks offer rather simple creations for such purposes. There are classes to create frame windows, toolbars, client windows, controls of all types (including tabbed 'pages', tree controls, list controls with headings, etc). The raw C method for doing these things is daunting. The GUI frameworks make these tasks nearly trivial (well, some of them).
