I have a mysterious Infinite CView::draw loop. This Question Goes in depth

Let’s start by writing I do want to do most of the GUI in code and not register a factory and custom templates to create a giant mark-up uidesc file.

First of all, it was unclear by the documentation that I must make a factory class to a CView in order to name it and use the name in the class attribute; Not only to use it in the WYSIWYG editor. This is easily done.

If I add to a CViewContainer derived class a pointer to a child in order to pass it to add child, then the WYSIWYG editor complains about a serious error and does not crash.

Where and who is in charge of properly deleting pointers? If I add a delete statement in another destructor it is also error prone.

Should I use the pointer classes provided by VST sdk? cpp smart pointers? Simple pointers?

I realize I have more than one bug/issue but the concrete issue is:

I have a derived parent container. In it I have a row/col derived class for columns, each column is derived from CControl and has a custom draw method.

If I keep an vector of pointers for use it does not even start to render the CFrame and responds to clicks and debugging shows it draws. However, if I press continue I’m back in draw, ad infitum.

Thee addView is done only when the parent is added with the container event handler.

If I do not use a vector but pass in a new statement as an argument, and comment out the addView then it renders the underlying views succefully, but I do not have my control columns anymore.

What to do?

Hi and welcome,
to help you, it would be a good idea to post some code. It’s unclear to me what exactly you are doing.
But one thing which sounds odd is that you don’t want to use the uidesc markup but you use the WYSIWYG editor. You either use both or none of it. So maybe you first need to get rid of the WYSIWYG feature by not using the VST3Editor as a base class and use the VSTGUIEditor as your base class.
Then, if you put together your views by hand, there’s this hopefully simple rule:

The parent view is the owner of its children.

So a CViewContainer owns all the views you add to it and they will be automatically destroyed when the container is destroyed.

I hope this makes some things clear

1 Like

Thanks a lot for the (quick) help :).

First of all, I was not aware of VSTGUIEditor and I’ll read into it. Thanks.

Second, I have a dilemma about whether to code it all in a fast growing list of code files (My model is sophisticated and is three code units for now) or adapt and/or derive from CControls and CViews which are not exactly what I imagined the GUI to be, but are close enough so I can finally hear my model in the headphones :). Another cone to the second option is that many things I thought could be variable and even exposed as variables in the GUI itself will be lost to constant as dictated by the constancy of the uidesc or the WYSIWYG which does make laying out faster, and another pro is that I’m using sdk higher level elements which are stable and have tests already most of the time.

My gut tells me go with the stable gui elements, shorten the time you spend on it by using the WYSIWYG and start debugging the model ASAP.

I’m making a 4 additive synth layers FM in a waterfall, and other configurations of nodes, and also a smooth morph between “presets” in 3D with opengl.

I made a nice dB slider bmp with GIMP and I’m doing all in WYSIWYG with minor editing of the JSON. I already encountered an issue with it, it is buggy. Doesn’t agree to draw the bmp and falls back to WhiteCColor…

I posted here about it now.

Regarding the safe method of container owning all its views:

I have seen the private vector of CViews in the code.

Two questions:

  1. Am I allowed to have the pointers that it holds as well, as plain pointers, and not worry about destructors? No memory leaks?
  2. Will it call my destructors specifically?
  3. am I allowed to pass constructs of pointers with a new statement and not have the pointer in my scope at all?
  4. If I have more than on layer of containers, did you mean that the single top most containers have to hold the objects/pointers explicitly and exclusively?

Turned out to be twice as many questins :).

Which portions of code would be of help in helping me do you think? :slight_smile:

If you hold plain pointers somewhere, you must make sure that the pointers are removed when the view is destroyed, see IViewListener.

Who is calling which destructors? I don’t understand this question.

This is a c++ question, you should ask in a c++ forum. I cannot give you a crash course in c++. (I’m very bad in teaching…)

No, it’s a normal hierarchy, where the first layer owns its direct children, and the next layer also owns its direct children. If you remove one layer it will remove all its direct children and if a direct children is also a container than this child container also removes its direct children and so on.