Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong types in cef3lib.pas #49

Closed
PizzaProgram opened this issue Feb 25, 2017 · 7 comments
Closed

Wrong types in cef3lib.pas #49

PizzaProgram opened this issue Feb 25, 2017 · 7 comments

Comments

@PizzaProgram
Copy link

If {$DEFINE CEF_STRING_TYPE_UTF8} enabled, and {.$DEFINE CEF_STRING_TYPE_UTF16} disabled >>
some errors prohibit to re-compile.
Like:
cef3lib.pas(390,1) SHOULD BE:
procedure _free_string(str: PCefChar); cconv;

... otherwise this error appears:
cef3lib.pas(399,19) Error: Incompatible types: got "<address of procedure(PWideChar);StdCall>" expected "TCefStringUtf8.<procedure variable type of procedure(PChar);StdCall>"
Result^.dtor := @_free_string;

@dliw
Copy link
Owner

dliw commented Feb 25, 2017

Thanks for the report. As it says // Don't change this, unless you know, what you are doing, I didn't bother to test...

Which version of fpCEF are you using? Somehow the line numbers don't match and I get different compile errors.

I hope you are aware, that one needs to have a custom compiled version of CEF with a different string type for this to work correctly.

@dliw
Copy link
Owner

dliw commented Feb 25, 2017

Thinking a bit more about the effects of this define, I think a lot more needs to be changed to properly support this. E.g. ustring then should change from WideString to AnsiString, which may also make changes necessary in the LCL and example code.

So unless you have really good reasons for this or provide a patch, I'd say changing this define simply is not supported.

@PizzaProgram
Copy link
Author

PizzaProgram commented Feb 25, 2017

We are trying to compile one big DLL file from the whole thing, so we can deploy next to our EXE (written under Delphi7).
But we are facing many problems with this concept.

I've thought one problem could maybe caused because the different coding, as we use UTF8 in the whole DLL, and the data exchange is in that format too.
Lazarus default coding is in UTF8 too. So why not using the default? Why do we have to convert to UTF16? (LE ?) It just did not make too much sense to us.

Many THANKS for the help!

@dliw
Copy link
Owner

dliw commented Feb 25, 2017

Just to be sure: You are using a custom CEF build compiled with CEF_STRING_TYPE_UTF8?

Your reasoning of course makes a lot of sense. To properly support changing the string type, two things must happen:

  • check, that the right string type is used everywhere
  • change ustring according to the defined string type, adapt LCL component code

I'm currently working on an update to a newer CEF version, but I will try to make those changes, once the update is done. However, I probably won't "support" this feature, as this would make testing much more difficult for me and compiling CEF does not make much fun 😞

@dliw dliw removed the wontfix label Feb 25, 2017
@PizzaProgram
Copy link
Author

PizzaProgram commented Feb 27, 2017

Sorry for all the trouble I've caused, thought it would be only a few definitions to correct... and thanks for the quick response again! Currently we are trying a completely different approach to our task: [http://www.cadetill.com/gmlib_en/](GMLib) So maybe we won't need to deal with chromium at all.

@dliw
Copy link
Owner

dliw commented Feb 27, 2017

Thanks for your feedback.
I'm reopening this issue again, because at least the wrong types cef2lib.pas are definitely a bug. Even if changing the string type is not supported, there should be no compile error when changing the defines.

@dliw dliw reopened this Feb 27, 2017
@dliw dliw changed the title Allowing UTF8 > compile errors Wrong types in cef3lib.pas Feb 27, 2017
@dliw dliw closed this as completed in 7d9cf2f Mar 2, 2017
@dliw
Copy link
Owner

dliw commented Mar 2, 2017

String types are correct and changing the CEF string type should now be possible (I didn't test it though).

I didn't touch the examples, although the explicit string conversion needs to be adapted, if the string type is changed. Anyway, in the future (and with fpc> 3.0.0), it is probably better to simply assign strings and leave the string conversion to the compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants