David Heffernan

Perfect for making images contain partial faces!

For 32 bit it's just Get8087CW and Set8087CW, but your real problem is still identifying the specific point in the code where it is changed.

This isn't to do with project settings. These settings are owned by the thread and something is changing them. By the sounds of it that something is an external DLL. If so you need to save the fp control word before you call the dll and restore that saved value when the dll call returns.

It has been demonstrated this is only possible using include files. I'm not sure what you can expect to find in a book that can add to this knowledge, and I doubt very much that ALL CAPS is going to unlock any blockage. Perhaps more likely is that what you are remembering was how to split something other than interface and implementation parts of a unit.

I'm sure you can do this easily enough with tools like obs

Attempts to build multiple projects in a group lead to out of memory errors on my XE7 Delphi. I guess things are somewhat better in later releases.

I don't think it should be either or, why can't we have both? Instead if often seems that we have neither.

Clearly there is a problem but you'd need to provide information on what the data is and precisely how you are processing it before you can get specific help. One thing I can probably say with confidence is that you are falling into the well know Delphi memory stream anti pattern.

Why do you want Embarcadero C++? What in particular are you looking for that is specific to Embarcadero tools rather than standard C++?

I bet Peter hasn't even written to Embarcadero!!

As I demonstrated in my previous comment what you are looking for is impossible so clearly you must have misremembered.

There's no other way. The interface and implementation sections of a unit must be in a single translation unit and the only way to have multiple files in a single translation unit is with include files.

Previous comments from Andy

I have the feeling that Andy is quite happy not to have to keep chasing updates.....

Even this can happen if the developer is splitting time between two different projects.

Merge conflicts happen whether or not the team is using branches or all developing on a single branch. If there are never any conflicts then it doesn't make much difference if you use branches or not. If there are conflicts then they can be a massive problem on long lived branches. But if there are no branches then they are also a massive problem. Often developments are in flux. Devs try something. Realise it was the wrong idea. Try something else, and so on. If this happens without branches then everyone has to deal with the conflicts over and over again. That's more work. Well managed branches make this easier. There never are magic bullet solutions for tough problems like this. You have to keep an open mind and do what works best for their teams.

This is a good point. Perhaps some settings suit a process with no branches. But This can't be right. You can't ever "prove" such a statement. There's never going to be a one size fits all approach. We all have to do what works for us, and be prepared to entertain new ideas and approaches.

Branch management requires skill but it's perfectly possible. You just need to know how to do it.

It's not so much how many branches. It's how long they live and how regularly changes from the develop branch get pulled into them. The other issue that can bite is when you have multiple branches working on the same area of code, for obvious reasons. But I don't think you should be afraid of having many feature branches so long as they are managed properly.

Delphi IDE integration for vcs isn't very good. I'd use another tool for that.

That's right. Which is essentially what the example in my comment was meant to demonstrate.

This question is basically like asking why TButton(ListBox) fails when ListBox is a TListBox. That's directly analagous to your cast.

I don't think you understand what we are saying. On a feature branch you develop a new feature that hasn't yet been released. So if there is a bug in code that has been released it doesn't clash with your new feature, because the feature is new. So the scenario you describe basically doesn't arise. You asked for advice, and we all have experience of this. You don't. Which is why you asked. Just a suggestion. Perhaps our experience means something? Or perhaps I don't understand how you develop. Perhaps you really do rewrite your entire code base regularly.

I don't think so. If the bug is in the code for the new feature then you don't need to push it to the release branch because this new feature hasn't been released. Of course you will sometimes be working on a feature that involves modifying existing code, and those modifications clash with a bug fix for released code. But if there is a clash then of course you have to fix it on the main dev branch, and then work out how to push that to any release/feature branches resolving conflicts. No workflow can avoid that. I'm sure other people can chip in, but in my experience, the vast majority of bug fixes can be resolved and then pushed to release branches without conflicts needing to be resolved.

Not really, the vcs does the work. You fix the bug once and then push it onto whichever branches also need the fix. Irrespective of the workflow you are going to do the fix once, commit it, and then use the vcs to propagate that fix to wherever you choose.