Gord P

Are you talking about changing the default name of Button1 for example to btnOpen or something? If so, I have never seen any guidelines for C++. I have seen a bunch of code written with a three letter lowercase prefix of the control such as the btnOpen one I just mentioned. I have seen mnuOpen for menu item, dlgOpen for dialog, actOpen for actions etc. I have my own system which is different. I think the main thing is being consistent and something you can search easy enough. Or perhaps someone will point you to some standard somewhere.

Yeah, it isn't intuitive or easy. I was hoping they would eventually massively improve it. Going through Ray's video really helps though. Glad you got what you needed.

A simple way to do that would be to add the Onyx Blue style to your project. Then set the StyleName property *of the button* to Onyx Blue. Otherwise if you want more control over the exact color, you will probably have to use the Bitmap Style Designer. Ray Konopka has an excellent video on YouTube on how to use it. If you don't want to do either of those, you might be able to use the Image and HotImage properties. I have not gone that route, so I don't know if it works. You would probably have to deselect seClient item in that case I would guess. edit: in my original reply, I forgot the words "of the button" in the sentence above, which is critical.

After watching the latest Webinar on C++Builder by David Millington, I would say that the answer to my question is: Extremely low to nil. Although he did not explicitly say it. He talks about 32 bits at around the 55 min mark.

Good to know.

I don't have any basis for my pessimism other than my experience with these kinds of things. Oh I definitely expect that to be the case for me.

Yes I am aware. But when I looked at switching over to Clang from the Classic compiler it appeared that there would be a lot of changes to my code that I would have to make so I put if off. You are right in that I could start the transition now with the old Clang but I am guessing (perhaps incorrectly) that there will be issues switching from the old Clang tool chain to the new one. So I would rather just go to the new one and skip all that. Plus for some reason, Code Completion doesn't work for me when using the old Clang compiler (11.3). That's what I am hoping for. But it would be nice to hear it from Embarcadero. I wish they would go back to giving road maps - even with all the disclaimers. At least you get a bit of an idea of what they are thinking. Thanks for your thoughts.

I would like to move away from the Classic compiler to the Clang compiler. My project that I would like to do that with is large enough than when I looked at making the move a while ago there appeared to be a lot that I was going to have to change so I continued on the Classic compiler. With the new Clang based c++ tool chain, making the move is more enticing. However, to use the new tool chain there are two transitions at the same time I have to make. One is to Clang and the other is 64 bits. Since 64 bits isn’t crucial for the program, I would like make the transition to the new Clang toolchain in 32 bits. Once the bugs have been worked out. Then migrate it over to 64 bits. Anyone hear anything on how likely that is? I put in a feature request for it. RSS-2237

I sure don't think so. Assuming something is initialized is a bit dangerous IMO.

Was the chart dropped on the form at design time, or was it created at run time? If it was the former, I would be curious as to whether the issue exists if it gets created by code. I am guessing not, but don't know. I have had problems with TCharts that were placed at design time when moving from one version of Rad Studio to another because they use the old TChart files/headers and it screws things up.

Thanks Anders, I'll check them out.

The pow(x, y) function is a bit of a bottleneck for me. My exponents have to be doubles so I can't trade it out for multiplication routines. After searching around, I see that this is a common issue in c++ and there is no simple fix. I'm just curious if others had come across something to help speed things up. Accuracy is an issue for me, so approximate solutions aren't appropriate.

Good to know. Thanks.

I was afraid someone might ask me to clarify that so I went through some older code hoping to find comments I left behind in the constructor or the OnShow event that might have explained where I ran into problems previously. Alas, my commenting skills are gradually getting better, but started from a weak place. I *think* I ran into issues with either (or both) some UI stuff that wasn't created yet for some reason and/or calling a function. I could totally be wrong here, but I just remember having some issues at some point a while back. I suppose the thing to do, would be to try it in the constructor again and see if anything arises during the build because for sure the constructor only gets called once.

Thanks. (I don't have Delphi, but I got the gist from the code). I guess I should have been more explicit. The main form will not be programmatically hidden (i.e. the main form's Visible property will not be set to false, and its Hide() method will not be called). I was just wondering if something in Windows could trigger an OnShow event even if I don't trigger one intentionally myself. Simply minimizing and restoring doesn't trigger it. I don't know if there is something else that might. I don't think so, but was just wondering.