Autocomplete on methods of function parameters about ideu

[fredvs]

I fear that for tuning autocompletion, it will done after the next release.

;-(

[circular17]

No problemo. The issue can wait patiently

[circular17]

So ready to publish a new release?

[fredvs]

Even, maybe for this release, we can disable insert/append code while 2xclick.

Imho, code completion should be revised and re-thinked.

[fredvs]

So ready to publish a new release?

I wait for your green light.

[circular17]

Hmm I think we forgot this issue:
mse-org/mseide-msegui#9

I also just found a tiny thing:
#33

[fredvs]

Hmm I think we forgot this issue:
mse-org/mseide-msegui#9

Huh, was it not solved?
Of course if you need a .prj fully compatible with MSEide, you should use, as explained, for target name: myfilename${EXEEXT}

This will work for both MSEide and ideU.
And for people that does poly-compilation with ideU, they know how to tune project-options for poly-compilation.

[fredvs]

Do not forget that a .prj saved by ideU has extended info that will be ignored by MSEide.
For example MSEide has options M B 1 2 3 4.
IdeU has options M B 1 2 3 4 5 6 7 8 9 0.

When you load a .prj with MSEide, options 5 6 7 8 9 0 are ignored.
The same for extension, MSEide has only one extension macro (${EXEEXT}), ideU has 12 macros + ${EXEEXT} .

Do you have problem to compile ideU.prj with MSEide from last commits?
It uses ideU${EXEEXT} as target name.

[circular17]

Not from MSEide but from ideU. With the following config:

I get the filename "demo.exe.exe"

[fredvs]

Yes, of course because you added ${EXEEXT} in the target file name.

For shared-project that must be MSEide compatible, for example using ideU${EXEEXT} , I set the exe extension like this:

[fredvs]

Ooops, I will do for ideU, thanks to note it.
Done in commit 40b1ac9

[circular17]

Hmm there may be a misunderstanding.

What I am talking about is that if there is already ${EXEEXT} in the end of the target file name, it would help not to append yet another extension.

To get the output file name that would be for example in pseudo-code:

function GetOutputFilename: string;
var
  fixedTargetFile, extension: string;
begin
  fixedTargetFile := Config.TargetFile;
  if not UpperCase(fixedTargetFile).EndsWith('${EXEEXT}') then
    AppendStr(fixedTargetFile, '${EXEEXT}');
  if Config.MakeExtension = '(Default)' then
    extension := GlobalConfig.EXEEXT 
  else 
    extension := Config.MakeExtension;
  result := StringReplace(fixedTargetFile, '${EXEEXT}', extension, []); 
end;

[fredvs]

Yes, I perfectly understood what you explained.

What can be done (maybe) in pseudo code:

if not UpperCase(fixedTargetFile).EndsWith('${EXEEXT}') then
    AppendStr(fixedTargetFile,exeext[NumofOption]);

[fredvs]

Hum, if we follow your idea, it must be done not only for EndsWith('${EXEEXT}') but also for any extension added in the targetfile name.

For example, if you do:

MyTargetfilename := 'myprog.exe', it should also forget the exeext[NumofOption]

[circular17]

if not UpperCase(fixedTargetFile).EndsWith('${EXEEXT}') then
    AppendStr(fixedTargetFile,exeext[NumofOption]);

Yes that would give some compatibility.

Then you need to remove ${EXEEXT} in "target file" to customize the extension, so that won't be compatible with MSEide anymore once you use this feature. Right?

[circular17]

Hum, if we follow your idea, it must be done not only for EndsWith('${EXEEXT}') but also for any extension added in the targetfile name.

For example, if you do:

MyTargetfilename := 'myprog.exe', it should also forget the exeext[NumofOption]

That's a good point.

Maybe to avoid this problem, when the Default extension is chosen, just do like MSEide.

[fredvs]

Maybe to avoid this problem, when the Default extension is chosen, just do like MSEide.

You know, the engine is already open, my hands full of grease, I will add the simple

if (pos('${EXEEXT}',uppercase(targetfilename)) > 0) or (pos('.',targetfilename) > 0) then dontaddextension;

[circular17]

Hmm well but if someone wants to add a dot in the filename?

Like MyProgram.v2.exe?

Though that's not essential. But when you say "donaddextension", would it still replace ${EXEEXT} with the custom extension?

[fredvs]

OK, could you try with last commit dbc1212 ?

Like MyProgram.v2.exe?

And, no problems, I do not see the problem.

[fredvs]

would it still replace ${EXEEXT}

Of course.

[circular17]

I understand what you did. At least that allows to keep the compatibility.

would it still replace ${EXEEXT}

Of course.

Well no it won't replace by the custom extension selected in the Exe extension tab. But that's ok I guess because if you start to customize the extensions then probably your project won't be compatible with MSEide anyway.

[circular17]

I tested it works. Thanks

[fredvs]

Well no it won't replace by the custom extension selected in the Exe extension tab.

OK, in last commit 409cfd3 there is that hint:

[circular17]

Ok.

[fredvs]

Note that the macro ${EXEEXT} is considered as a extension, like .exe.

[fredvs]

MyProgram.v2.exe

You may try, it will work.

[circular17]

Yes but I was thinking in "target file" to have "MyProgram.v2" and then to select .exe in the extension list.

[fredvs]

Ha, hum, ok, maybe a new check-box should be added "Add always extension"?

[circular17]

Hmmmm...

Or my previous suggestion (simplified):

• if Default extension is selected, do as MSEide: replace ${EXEEXT} by global extension
• otherwise remove ${EXEEXT} and add selected custom extension

[fredvs]

if Default extension is selected

You mean in Tab "Exe Extension" ?

do as MSEide: replace ${EXEEXT} by global extension

Hmmmm, so first look was selected in tab and then do the check...
Re-hmmmmm, let me think about it.

[fredvs]

OK, it is late, but imho, this should work too:

First delete any ${EXEEXT} in target file name.

int1 := system.pos('${EXEEXT}',uppercase(targetfile));
if int1 > 0 then targetfile := system.copy(targetfile,0,int1);

Then do as usual, use the selected extension....

I did commit this in 5e6f44a, what do you think?

[fredvs]

OK, recommitted, this is the good one : 73bae4f

[circular17]

Hmm the code is not very readable. Can you use meaningful variable names instead of int2, int3, int4 etc. ?

Also seems that the code is duplicated in projectoptionsform.pas and make.pas. Is it possible to put that in one function?

[fredvs]

Also seems that the code is duplicated in projectoptionsform.pas and make.pas. Is it possible to put that in one function?

No, it is not the same function, one is to define the target file, the other is to create the compiler command line.

[fredvs]

Hmm the code is not very readable. Can you use meaningful variable names instead of int2, int3, int4 etc. ?

Done in commit 1171ad4

[circular17]

Great. I tested it that's very good now.

I guess you can publish it

[fredvs]

OK, many, many thanks for all your help and lucidity.

There is some few things to tune before release but imho, it is nearly ready.
I will do it next week because I want to test it deep on each OS before to post the executable.

Have a perfect Sunday.

Fre;D

[fredvs]

If I have the following code:

procedure tmainfo.formpaint(const Sender: twidget; const acanvas: tcanvas);
begin
  acanvas.fill

Yes, it should show the list.
I fear that this issue could be fixed only by a class-guru.

;-)

[circular17]

Hmm where will we find that?

[fredvs]

Afaik in sourceupdate.pas, function composeprocedureheader....

https://github.com/fredvs/ideU/blob/master/src/sourceupdate.pas

[circular17]

No I was talking about the guru