Leaderboard

I finally have a solution with the help of GEXPERT @dummzeuch source It says "// If this starts crashing try IDesigner.CreateComponent" So I did var IDs: IDesigner; change create component to ids := (CurrentForm as INTAFormEditor).FormDesigner; if Assigned(IDs) then IDs.CreateComponent(TComponentClass( Tlabel),GxOtaGetNativeComponent(lComponent),0,0,50,50) ; I hop i did OK Any further help will be appritiated For me, it worked on D10.2.3 this is what I needed.

Delphi IDE uses System.Classes.TStream.WriteDescendentRes to serialize the form/components properties. Property that belongs to the class is handled by System.Classes.TWriter.WriteProperty. However internal property such ExplicitXxx is handled by System.Classes.TWriter.DefineProperty. // TPersistent.DefineProperties defines Explicit properties. and TWriter.DefineProperty encode them. procedure TControl.DefineProperties(Filer: TFiler); begin ... Filer.DefineProperty('IsControl', ReadIsControl, WriteIsControl, DoWriteIsControl); Filer.DefineProperty('ExplicitLeft', ReadExplicitLeft, WriteExplicitLeft, not (csReading in ComponentState) and DoWriteExplicit(edLeft)); Filer.DefineProperty('ExplicitTop', ReadExplicitTop, WriteExplicitTop, not (csReading in ComponentState) and DoWriteExplicit(edTop)); Filer.DefineProperty('ExplicitWidth', ReadExplicitWidth, WriteExplicitWidth, not (csReading in ComponentState) and DoWriteExplicit(edWidth)); Filer.DefineProperty('ExplicitHeight', ReadExplicitHeight, WriteExplicitHeight, not (csReading in ComponentState) and DoWriteExplicit(edHeight)); end; In a nutshell, hooking TWriter.DefineProperty will get you off EplicitXxx: procedure InterceptDefineProperty(Obj: TWriter; const Name: string; ReadData: TReaderProc; WriteData: TWriterProc; HasData: Boolean); begin // do nothing !!! or write a filter to allow certain ExplicitXxx. end; // install the hook : DefinePropertyPtr := GetProcAddress(GetModuleHandle('rtl260.bpl'), '@System@Classes@TWriter@DefineProperty$qqrx20System@UnicodeStringynpqqrp22System@Classes@TReader$vynpqqrp22System@Classes@TWriter$vo'); @TrampolineDefineProperty := InterceptCreate(DefinePropertyPtr, @InterceptDefineProperty);

There are some odd entries in the resources of BDS.EXE and BDS.fr: And some other executables do not have proper version info: So they do not display anything when read the usual way (like e.g. in the Properties dialog in Windows). Older Delphi versions still refer to Appmethod in the translations (this is XE8): (I definitely had too much time on my hands today. 😉

Got it to work. Now the GExperts PEInfo tool also shows all strings in all languages stored in the version info resource which includes the non-standard once like BuildDateTime:

As far as I remember there's no API for that. I think you will have to parse the resource block yourself. If you're lucky the memory layout is the same as the RES layout but even then many of the structures in the VERSIONINFO RES format are undocumented or very poorly documented. The only suggestion I have is to have a look at the source of Collin Willson's old resource editor and see how he did it (with regard to the RES format).

I can reproduce the initial screen being too small on my 3840x2160 monitor. But it would be sufficient to fix the failure to save the size between usages, to avoid the annoyance of resizing it every time, and this might not require a matching monitor. I am sorry, but I am not motivated to learn enough about the Gexperts source to discover how/where you prefer to save dialog sizes, because this is a Gexperts item that I have never used!

In theory they are used to preserve the original size and position of controls when they are set to alClient, alTop etc. so when they are set back so alNone at a later time, they automatically revert to their original size and position. Personally I never found that useful and since these values tend to change very often (no idea why, they shouldn't) they pollute the DFM diffs and history.

If you are not working in A, B and C then you simply should never see any conflicts. My guess is that someone in your organisation is using git incorrectly. No reason at all that you should have any troubles with all this in a single repo.

I'm not clear enough in what git is doing to explain this much better, but here's what I think is happening... You make some changes to code in folders A, B, and C, while I'm working in P, Q, and R. I set up a branch and do a pull from master. It updates the files in my local A, B, and C folders, because you made changes to them. I'm not touching them. I make some changes to P then go home. In the morning I come in and do a git pull and get a bunch of stuff from A and C that you've been working on today. I finish up work on P, commit it, try to push it, and then I get a warning from git saying it cannot push because of a conflict in some files in A. So I have to stop what I'm doing and figure out what in the hell is the problem with files in a unit I had nothing to do with that's preventing me from pushing my changes in P into master. I've got customer service people pestering me to get these changes pushed into production ASAP, and you're at lunch, and whatever I do to proceed is going to screw up your work. This is what we're running into. I'm probably not even explaining it fully accurately, and it probably suggests we're doing something wrong. But all that sticks in my mind is that this issue is arising because of timing dependencies between when you pushed some stuff to git, when it got copied down to my local repo, when you then made some updates, caused a conflict yourself, and that got pulled to my local repo before you resolved it. So that left it to ME to resolve locally. In these situations (which have come up at least a dozen times in the past couple of weeks), I can neither pull nor push anything until I "resolve" the issues in YOUR code on MY local repo. I notify my boss who goes haywire, immediately sets up an emergency video conf call with 8 people, and we all spend 45 minutes trying to fix this mess. And the bottom-line is that people point their fingers at ME for screwing something up. All I know is, I did not touch any of the files in either A, B, or C, and everybody gets their knickers in a wad when I say that because it makes me sound defensive and trying to shift the blame. From MY perspective, I just keep asking, "Why in the world can't I just work on the files in folders assigned to me and not have to deal with all these other folders getting their files updated and having issues when they have nothing to do with anything I'm working on?" I'm still relatively new here, and the guy who has been single-handedly maintaining this code for the past several years left, but he made it all look like a walk in the park. We are now tripping over ourselves every other day with weird stuff like this that everybody says should not be happening. I'm pretty sure we're doing something wrong in how we're interacting with git. But we've been given three different scripts to follow now, and they all seem to result in the same problems coming up, but at different times and contexts.