Kryvich

Yes, wrapping to the record type is possible. Though having the [optional] strong type checking for these types would be better. Detecting a possible error at compile time is much better than at runtime, right? The language already has everything to implement this: type // Aliases, no type checking on assignment TDistanceMeters = Double; TDistanceMiles = Double; // New custom types, [optional] type checking on assignment is needed TDistanceMeters = type Double; TDistanceMiles = type Double;

But will this be the right solution? These types have different sizes (tested for Win32): if SizeOf(Pointer) <> SizeOf(TWndMethod) then ShowMessage('No way.'); // 4 <> 8 I tried this: var i64: UInt64; ... i64 := fld.GetValue(TabSet1).AsUInt64; proc := TWndMethod(i64); But get Exception EInvalidCast 'Invalid class typecast' for GetValue.AsUInt64. Update. I did it like this: var p: Pointer; ... p := fld.GetValue(TabSet1).GetReferenceToRawData; proc := TWndMethod(p^); Thanks @Lars Fosdal for the hint!

Exactly! Let this check be disabled by default. Actually Unicode strings (WideString type) existed before converting VCL to Unicode. Try it in Delphi 2007 - no warnings, but there is conversion error: procedure TestAnsiWideString; var ansiStr: AnsiString; wideStr: WideString; begin wideStr := #1055#1072'-'#1073#1077#1083#1072#1088#1091#1089#1082#1091#13#10 + #12498#12517#12540#12473#12488#12531#12289#31169#12383#12385#12395#12399#21839#38988#12364#12354#12426#12414#12377#12290; ansiStr := wideStr; if wideStr <> ansiStr then Writeln('Houston, we have a problem.') end; But they added the Ansi <---> Unicode check, because it became a massive problem when moving to Unicode.

@Arnaud Bouchez If someone don't care about the strong typing, these hints and warnings can be mooted selectively, locally for a code block or globally for a project. {$WARN STRONG_TYPE_CHECKING OFF} They have already added improved type checking for string types when there is an implicit ANSI <--> Unicode conversion: [dcc32 Warning] W1057 Implicit string cast from 'AnsiString' to 'string' It is very useful in many cases. So I see no problem adding the same check for other simple types, the built in ones or created by the user. As for type helpers, the compiler might allow their use for spawned user types if the strong type checking warning I suggest is disabled.

@David Heffernan No need to change the language. We need a small revision of the compiler so that it shows a hint or warning. Such checks can be added to a third-party tool similar to FixInsight. But having additional type checking right in the compiler would be much better.

@Rollo62 Nothing will change. Delphi allows implicit conversions between different types spawned from one common type (String, Integer, Double etc.). In fact, I wrote about this even 10 years (or so) ago in the old Delphi.Non-Tech forum. Unfortunately, no new warnings or compiler hints have been added since. Strong typing worth nothing while we can write it as miles := meters * Pi + Application.MainForm.Width; // Another example with a comparison miles := TDistanceMiles(100); meters := TDistanceMeters(100); if miles = meters then ShowMessage('Hi, it is your compiler!'); without any warning or hint from the compiler.

Slides 74-76. Strongly-Typed Pascal !!! Someone in Embarcadero should hear programmers request and help to make the implicit explicit in such situations: program TestMetersToMiles; {$APPTYPE CONSOLE} type TDistanceMeters = type Double; TDistanceMiles = type Double; function ConvertMetersToMiles(Distance: TDistanceMeters): TDistanceMiles; begin Result := TDistanceMiles(Double(Distance) / 100000 * 62.14); end; var meters: TDistanceMeters; miles: TDistanceMiles; begin miles := 100; // No syntax error, no warning, no hint meters := ConvertMetersToMiles(miles); // No syntax error, no warning, no hint end. I've complained already about this here.

Regarding the naming of units. It makes sense to name a unit like this: ProjectName.UnitName.pas. ProjectName can be the abbreviated name of your project. And if the project is really big (like Delphi) - add the name of the subproject instead, for ex.: System.Types, Vcl.Forms, FMX.Forms etc. An even Subproject.Subproject.UnitName.pas: FMX.Forms.Border.pas, FMX.ListView.Appearances.pas...

Thanks to @Arnaud Bouchez for his great framework mORMot. It makes complicated things simple.

Each of us was in such a situation. See, this is a ready-made working example. You can use it as a basis: program TestPostRequest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, SynCrtSock; const RequestHeaderTemplate = 'SOAPAction: http://tempuri.org/IConsultaCFDIService/Consulta'; RequestDataTemplate = '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">' + ' <soapenv:Header/>' + ' <soapenv:Body>' + ' <tem:Consulta>' + ' <!--Optional:-->' + ' <tem:expresionImpresa><![CDATA[%expresionImpresa%]]></tem:expresionImpresa>' + ' </tem:Consulta>' + ' </soapenv:Body>' + '</soapenv:Envelope>'; function SendCommand(Request: THttpRequest; const ExpresionImpresa: string): SockString; var outHeaders: SockString; begin Result := ''; try Request.Request('ConsultaCFDIService.svc?wsdl', 'POST', 20000, RequestHeaderTemplate, SockString(StringReplace(RequestDataTemplate, '%expresionImpresa%', ExpresionImpresa, [])), 'text/xml;charset="utf-8"', outHeaders, Result); except on E: Exception do begin Writeln('Error: ', E.Message); Exit; end; end; end; var Request: THttpRequest; Answer: SockString; begin try Request := TWinHTTP.Create('consultaqr.facturaelectronica.sat.gob.mx', '', True); try Answer := SendCommand(Request, '?re=LSO1306189R5&rr=GACJ940911ASA&tt=4999.99&id=e7df3047-f8de-425d-b469-37abe5b4dabb'); Writeln('Answer:'); Writeln('----------------'); Writeln(Answer); Writeln('----------------'); // Next requests go here ... finally Request.Free; end; Writeln('Press Enter to continue.'); Readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

@Mr. E Have you tried my SoapClient attached to the previous post? UseWSDL = False. RIO.URL = https://consultaqr.facturaelectronica.sat.gob.mx/ConsultaCFDIService.svc -- this is the service you need, right? It is listed in "Ejemplo de consumo HTTP" you provided. Soap client uses POST request over HTTPS. The request returns "CodigoEstatus: S - Comprobante obtenido satisfactoriamente.", the same as indicated in "Respuesta obtenida". But you can use other third-party library, or prepare and call HttpSendRequest manually, it is in WinApi.WinInet. I can recommend THttpRequest class from SynCrtSock.pas, mORMot. Something like this: fHttpRequest.Request( 'https://consultaqr.facturaelectronica.sat.gob.mx/ConsultaCFDIService.svc?wsdl', 'POST', 20000, InHeader, inData, ' text/xml;charset="utf-8"', outHeaders, outData); P.S. Oh, you wrote "has been doing changes". Well then you always can use THttpRequest class and modify the request as you need.

When you are viewing the contents of a form, Delphi substitutes Unicode characters with the corresponding codes in #nnnn format. (This is valid for Delphi 10.2.3 and earlier, I do not know how it will be in 10.3). Therefore, manual editing of text strings of form elements is very difficult. After installing the Kryvich's Forms Humanizer package in your IDE, you can use a simple keyboard shortcut Ctrl-Alt-H to "humanize" all the text strings in your form's editor. This means that codes like #nnnn will be replaced with the corresponding Unicode characters. You can download and test the plugin for free here: https://sites.google.com/site/kryvich/kryvichs-form-humanizer. Enjoy!

For those who have installed this plugin: today, 11.11, KFH has been updated to version 1.1. Now you no longer need to convert the characters back to the #nnnn format before saving the changes. And yes, the Forms Humanizer supports not only VCL and FireMonkey forms and frames, but also data modules.

@Mr. E You have to import the WSDL scheme, and Delphi generate necessary code for you. Create New VCL Form Application. File | New | Other | Delphi Projects | WebServices | WSDL Importer Location of WSDL file: https://pruebacfdiconsultaqr.cloudapp.net/ConsultaCFDIService.svc?singleWsdl In the generated unit ConsultaCFDIService replace all "https://pruebacfdiconsultaqr.cloudapp.net/ConsultaCFDIService.svc" to "https://consultaqr.facturaelectronica.sat.gob.mx/ConsultaCFDIService.svc" Use function GetIConsultaCFDIService to obtain IConsultaCFDIService in the generated unit. Demo application is attached. Tested in Delphi 10.2.3 Community edition. SoapClient.ZIP

I am trying to write a small plug-in to the Delphi IDE using ToolsAPI. (If I succeed, it will be distributed free of charge.) 1. Is it possible to reset the status of a file in editor after changes via IOTAEditWriter? Here is IOTAEditor.Modified but It's readonly. Or somehow make him think that the file has already been saved. 2. Is it possible to hook view mode switchings for opened DFM/FMX forms (View as Form / View as Text), using ToolsAPI only?

@David Millington Yes, thank you. It's looks like a right direction.

OK I just registered too. Looks not bad. http://community.idera.com/developer-tools/p/forums While there is not crowded, but who knows... Activity stream: http://community.idera.com/developer-tools/ A new article in the Idera's Community: New in RAD Studio 10.3: Options Dialog Improvements (I have not seen 10.3 yet, but I like it more and more :) )

Good joke: invite and lock the door.

It seems there is no simple solution for 1). Need to learn more. As for 2) yes, I thought about notifiers. Then I need to know When an user opens a form and creates a new one, to set notifiers for this form. When an user toggles between design mode and text mode of the form. Creating plugins for IDE is an interesting thing. Thank you for articles, I have to study it more deeply!

@David Hoyle 1) Just setting the Modified status of IOTAEditor (or corresponding IOTAModule) to False would be fine. 2) The plugin must perform certain actions when an user toggles any open form from design view to text view, and back. Actually it's the Forms Humanizer plugin, I wrote about him here:

@Stefan Glienke I do not argue with the solution proposed by Gabrijelčič. But I would like to be warned when parameters of a wrong type are passed to API functions. A small hint from the compiler would help avoid difficult-to-find errors.

In the right pascal way it would be like this: type TUrl = type string; TProto = type string; THost = type string; TPath = type string; TConnector = class public procedure SetupBridge(const url1, url2: TUrl); overload; procedure SetupBridge(const url1: TUrl; const proto2: TProto; const host2: THost; path2: TPath); overload; procedure SetupBridge(const proto1: TProto; const host1: THost; path1: TPath; proto2: TProto; const host2: THost; path2: TPath); overload; procedure SetupBridge(const proto1: TProto; const host1: THost; path1: TPath; url2: TUrl); overload; end; The type in "TUrl = type string" means that TUrl is a new different string type. Then you would need to specify the type of the parameter when calling: Connector.SetupBridge(TUrl('http://www.thedelphigeek.com/index.html'), TUrl('http://bad.horse/')); Connector.SetupBridge(TUrl('http://www.thedelphigeek.com/index.html'), TProto('http'), THost('bad.horse'), TPath('')); So are we safe? No! Unfortunately, Delphi allows assignments between custom string types. Connector.SetupBridge('http://www.thedelphigeek.com/index.html', 'http://bad.horse/'); Connector.SetupBridge(TProto('http://www.thedelphigeek.com/index.html'), TProto('http://bad.horse/')); There is no overloaded methods like "procedure SetupBridge(const url1, url2: TProto);". But the compiler will not give any warning or hint. I would like the compiler developers to add a hint in such situations, not only for the types generated from string, but also for any other types (Integer, Byte etc.)

I like to write code without warnings and hints issued by the compiler. Today I encountered the following warning: program TestCaseW1010; {$APPTYPE CONSOLE} type TPerson = class Name: string; function ToString(Quote: boolean): string; overload; end; function TPerson.ToString(Quote: boolean): string; begin if Quote then Result := '"' + Name + '"' else Result := Name end; var Person: TPerson; begin Person := TPerson.Create; Person.Name := 'John'; Writeln(Person.ToString); // --> TPerson Writeln(Person.ToString(False)); // --> John Writeln(Person.ToString(True)); // --> "John" Readln; Person.Free; end. The compiler shows W1010 Method 'ToString' hides virtual method of base type 'TObject'. In fact, he does not. Is it a false positive warning, or is it something wrong with my code?

They use tags nowadays. :)

Can someone suggests a really big open source project with plenty forms and units to test it on my Delphi 10.2.3 SE? Because I never seen no one exception in IDE after installing the Community Edition this summer. Though my projects not so big, a few hundred of thousand lines max. OK I opened JVCL package in my IDE, opened a few dozen files via Project Manager. I tried to compile, switch to form designer and back to code, type text. No problems. Even ErrorInsight works as expected. Bds.exe ate 370 megabytes of memory, but the IDE is still responsive. So far so good...