Multiplatform Programming Guide/es: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		Esta página es el comienzo de una tutoría sobre la creación de aplicaciones multiplataforma con Lazarus. Comprenderá tanto las precauciones necesarias para garantizar que un programa pueda ser fácilmente migrado y el proceso de migración de un programa ya existente. Todos están invitados a ayudar a mejorar el artículo.
2	2
3	3		## Introducción a la programación multiplataforma
4	4
5	5		### ¿Cuántas cajas son necesarias?
6	6
7	7		Para responder a esta pregunta, primero debes determinar quiénes serán los usuarios potenciales y la forma en que tu programa se utilizará. Esta cuestión depende de dónde vas a implementar la aplicación.
8	8
9	9		Si estás desarrollando una aplicación de escritorio genérica, Windows es, obviamente, la plataforma más importante, pero también incluye Mac OS X y/o versiones de Linux a veces puede ser la diferencia que haga que tu aplicación sea elegida en lugar de una aplicación no multiplataforma.
10	10
11	11		La popularidad de los distintos sistemas operativos de escritorio difiere según el país, por el tipo de aplicaciones utilizado, y por el público al que se dirige, así que no hay regla general. Por ejemplo, Mac OS X es muy popular en América del Norte y Europa occidental, mientras que en América del Sur los Macs se circunscriben principalmente a trabajos de vídeo y sonido.
12	12
13	13		En muchos proyectos por contrato una sola plataforma es relevante, y eso no es un problema. Free Pascal y Lazarus son capaces de escribir código destinado a una plataforma específica. Puede, por ejemplo, acceder a la API completa de Windows para escribir un programa de Windows, bien integrado.
14	14
15	15		Si estás desarrollando una aplicación que se ejecuta en un servidor Web, una plataforma Unix en uno de sus varios sabores es usada comúnmente. En este caso, tal vez sólo Linux, Solaris, *BSD y otros Unix tiene sentido como plataformas de destino, aunque es posible que desee agregar el soporte para Windows para que sea más completa.
16	16
17	17		Una vez que domines el desarrollo multiplataforma, por lo general sólo debes centrarte en el problema para el cual la aplicación se ha diseñado para resolver y hacer la mayor parte de su desarrollo en cualquier plataforma que dispongas o te sientas más cómodo. Es decir, una vez que has abordado todas las cuestiones multiplataforma en su diseño, se puede pasar por alto en gran medida las otras plataformas, tanto como lo harías en el desarrollo para una plataforma única. Sin embargo, en algún momento tendrás que poner a prueba implementar y ejecutar tu programa para las otras plataformas y será útil tener acceso sin restricciones a equipos que ejecuten los sistemas de destino con toda la información operacional. Si no deseas varias máquinas reales, usted puedes mirar en la configuración de una máquina de arranque dual Windows-Linux o con Windows y Linux en tu Mac a través de Bootstrap o bajo un emulador como Parallels, Virtual Box o VMware.
18	18
19	19		## Programación multiplataforma
20	20
21	21		### Trabajar con archivos y carpetas
22	22
23	23		Cuando se trabaja con archivos y carpetas, es importante usar delimitadores de ruta y de [[End of Line\|fin de línea]] no específicos de una plataforma\]. Aquí está una lista de declaraciones [[Constant\|constantes]] en Lazarus para usar cuando se trabaja con archivos y carpetas.
24	24
25	25		- PathSep, PathSeparator: separador de ruta al agregar varias rutas juntas (';', ...)
26	26		- PathDelim, DirectorySeparator: separador de directorio para cada plataforma ('/', '\\', ...)
27	27		- LineEnding: secuencia de caracteres correcta de final de línea (#13#10 - CRLF, \#10 - [[Line feed\|LF]], ...)
28	28
29	29		Otra cosa importante a señalar es el caso de la sensibilidad (a mayúsculas/minúsculas) del sistema de archivos. El nombre de archivo de Windows no distinguen entre mayúsculas y minúsculas, mientras que en las plataformas Linux y BSD es lo usual. Mac OS X usa nombres de archivo insensibles por defecto. Esto puede ser la causa de molestos errores, por lo que cualquier aplicación portable debe utilizar nombres de archivo de forma consistente.
30	30
31	31		Las funciones de archivo de la RTL utilizan la de codificación del sistema para nombres de archivo. En Windows esta es una de las páginas de códigos de Windows, mientras que Linux, BSD y Mac OS X suelen utilizar UTF-8. La unidad FileUtil de la LCL ofrece funciones de archivo que utilizan caracteres UTF-8 como el resto de la LCL.
32	32
33	33		``` pascal
34	34		// AnsiToUTF8 y UTF8ToAnsi necesitan de un gestor de ''widestring'' en Linux, BSD y MacOSX
35	35		// pero usualmente estos SO utilizan UTF-8 como codificación del sistema por lo que el gestor de ''widestring''
36	36		// no es necesario.
37	37		function NeedRTLAnsi: boolean;// cierto (true) si el sistema no es UTF-8
38	38		procedure SetNeedRTLAnsi(NewValue: boolean);
39	39		function UTF8ToSys(const s: string): string;// similar a UTF8ToAnsi pero más independiente delgestor de ''widestring''
40	40		function SysToUTF8(const s: string): string;// similar a AnsiToUTF8 pero más independiente delgestor de ''widestring''
41	41		function UTF8ToConsole(const s: string): string;// convierte cadenas UTF8 a la codificación de la consola (usado por Write, WriteLn)
42	42
43	43		// operaciones de archivo
44	44		function FileExistsUTF8(const Filename: string): boolean;
45	45		function FileAgeUTF8(const FileName: string): Longint;
46	46		function DirectoryExistsUTF8(const Directory: string): Boolean;
47	47		function ExpandFileNameUTF8(const FileName: string): string;
48	48		function ExpandUNCFileNameUTF8(const FileName: string): string;
49	49		function ExtractShortPathNameUTF8(Const FileName : String) : String;
50	50		function FindFirstUTF8(const Path: string; Attr: Longint; out Rslt: TSearchRec): Longint;
51	51		function FindNextUTF8(var Rslt: TSearchRec): Longint;
52	52		procedure FindCloseUTF8(var F: TSearchrec);
53	53		function FileSetDateUTF8(const FileName: String; Age: Longint): Longint;
54	54		function FileGetAttrUTF8(const FileName: String): Longint;
55	55		function FileSetAttrUTF8(const Filename: String; Attr: longint): Longint;
56	56		function DeleteFileUTF8(const FileName: String): Boolean;
57	57		function RenameFileUTF8(const OldName, NewName: String): Boolean;
58	58		function FileSearchUTF8(const Name, DirList : String): String;
59	59		function FileIsReadOnlyUTF8(const FileName: String): Boolean;
60	60		function GetCurrentDirUTF8: String;
61	61		function SetCurrentDirUTF8(const NewDir: String): Boolean;
62	62		function CreateDirUTF8(const NewDir: String): Boolean;
63	63		function RemoveDirUTF8(const Dir: String): Boolean;
64	64		function ForceDirectoriesUTF8(const Dir: string): Boolean;
65	65
66	66		// entorno
67	67		function ParamStrUTF8(Param: Integer): string;
68	68		function GetEnvironmentStringUTF8(Index: Integer): string;
69	69		function GetEnvironmentVariableUTF8(const EnvVar: string): String;
70	70		function GetAppConfigDirUTF8(Global: Boolean): string;
71	71
72	72		// otras
73	73		function SysErrorMessageUTF8(ErrorCode: Integer): String;
74	74		```
75	75
76	76		### Nombres de archivo vacios y delimitadores de ruta duplicados
77	77
78	78		Windows permite nombres de archivo vacíos, Linux, BSD y Mac OS X por contra no. Es por eso que FileExistsUTF8('..\\') comprueba en Windows un archivo sin nombre en el directorio padre. En Unix, como los sistemas Linux, BSD y OS X, un archivo vacío se asigna al directorio y los directorios se tratan como archivos. Esto significa que FileExistsUTF8 ('../') en Unix comprueba la existencia del directorio padre, que normalmente será verdadero.
79	79
80	80		Por la misma razón los delimitadores de ruta duplicados en un nombre de archivo tienen tratamiento distinto. En Windows 'C:\\' no es lo mismo que 'C:\\\\', mientras que en los *nix la ruta '/usr//' es equivalente a '/usr/', y si '/usr' es un directorio, incluso estas tres son iguales. Esto es importante cuando se concatena nombres de archivo. Por ejemplo:
81	81
82	82		``` pascal
83	83		FullFilename:=FilePath+PathDelim+ShortFilename; // el resultado tiene dos delimitadores de ruta y da resultados distinto en Windows y Linux
84	84		FullFilename:=AppendPathDelim(FilePath)+ShortFilename); // crea un solo delimitador de ruta
85	85		FullFilename:=TrimFilename(FilePath+PathDelim+ShortFilename); // crea un solo delimitador de ruta y es más limpio
86	86		```
87	87
88	88		La función TrimFilename reemplaza delimitadores de ruta dobles por un solo y recorta rutas '..'. Por ejemplo /usr//lib/../src es recortado a /usr/src.
89	89
90	90		Si quieres saber si un directorio existe utiliza DirectoryExistsUTF8.
91	91
92	92		Otra tarea común es comprobar si existe la parte de la ruta de un nombre de archivo. Puedes obtener la ruta con ExtractFilePath, pero este contendrá el delimitador de ruta. En sistemas Unix simplemente usa FileExistsUTF8 para la ruta. Por ejemplo FileExistsUTF ('/home/usuario/') será cierto si el directorio /home/usuario existe. En Windows debes utilizar la función DirectoryExistsUTF8, pero antes se debe eliminar el delimitador de ruta, por ejemplo con la función ChompPathDelim. En Unix el directorio raíz es '/' la función ChompPathDelim creará una cadena vacía. La función DirPathExists trabaja como la función DirectoryExistsUTF8, pero recorta la ruta dada.
93	93
94	94		### Codificación de texto
95	95
96	96		Los archivos de texto son a menudo codificados en el sistema de codificación actual. En Windows esto suele ser una de las páginas de código de Windows, mientras que Linux, BSD y Mac OS X suelen utilizar UTF-8. No existe una regla del 100% para saber qué codificación utiliza un archivo de texto. La unidad de la LCL lconvencoding tiene la función de adivinar la codificación:
97	97
98	98		``` pascal
99	99		function GuessEncoding(const s: string): string;
100	100		function GetDefaultTextEncoding: string;
101	101		```
102	102
103	103		Y contiene funciones para la conversión de una codificación a otra:
104	104
105	105		``` pascal
106	106		function ConvertEncoding(const s, FromEncoding, ToEncoding: string): string;
107	107
108	108		function UTF8BOMToUTF8(const s: string): string; // UTF8 with BOM
109	109		function ISO_8859_1ToUTF8(const s: string): string; // central europe
110	110		function CP1250ToUTF8(const s: string): string; // central europe
111	111		function CP1251ToUTF8(const s: string): string; // cyrillic
112	112		function CP1252ToUTF8(const s: string): string; // latin 1
113	113		...
114	114		function UTF8ToUTF8BOM(const s: string): string; // UTF8 with BOM
115	115		function UTF8ToISO_8859_1(const s: string): string; // central europe
116	116		function UTF8ToCP1250(const s: string): string; // central europe
117	117		function UTF8ToCP1251(const s: string): string; // cyrillic
118	118		function UTF8ToCP1252(const s: string): string; // latin 1
119	119		...
120	120		```
121	121
122	122		Por ejemplo, para cargar un archivo de texto y convertirlo a UTF-8 se puede utilizar:
123	123
124	124		``` pascal
125	125		var
126	126		sl: TStringList;
127	127		OriginalText: String;
128	128		TextAsUTF8: String;
129	129		begin
130	130		sl:=TStringList.Create;
131	131		try
132	132		sl.LoadFromFile('alguntexto.txt'); // Ojo: esta sentencia de cambia los delimitadores de final de línea a los del sistema
133	133		OriginalText:=sl.Text;
134	134		TextAsUTF8:=ConvertEncoding(OriginalText,GuessEncoding(OriginalText),EncodingUTF8);
135	135		...
136	136		finally
137	137		sl.Free;
138	138		end;
139	139		end;
140	140		```
141	141
142	142		Y para guardar el archivo de texto con la codificación del sistema usaremos esto:
143	143
144	144		``` pascal
145	145		sl.Text:=ConvertEncoding(TextAsUTF8,EncodingUTF8,GetDefaultTextEncoding);
146	146		sl.SaveToFile('sometext.txt');
147	147		```
148	148
149	149		### Archivos de configuración
150	150
151	151		Puede utilizar la función [[doc:rtl/sysutils/getappconfigdir.html\|GetAppConfigDir]] de la unidad SysUtils para conseguir un lugar adecuado para almacenar los archivos de configuración en diferentes sistemas. La función tiene un parámetro, llamado Global. Si es true entonces el directorio devuelto es un directorio global, es decir, válida para todos los usuarios del sistema. Si el parámetro global es falso, entonces el directorio es específico para el usuario que está ejecutando el programa. En los sistemas que no son compatibles con entornos multiusuario, estos dos directorios pueden ser el mismo.
152	152
153	153		También existe la función [[doc:rtl/sysutils/getappconfigfile.html\|GetAppConfigFile]], que devolverá un nombre apropiado para un archivo de configuración de la aplicación. Se puede utilizar de esta manera:
154	154
155	155		ConfigFilePath := GetAppConfigFile(False) + '.conf';
156	156
157	157		Estos son ejemplos de la salida de las funciones de ruta por defecto en diferentes sistemas:
158	158
159	159		``` pascal
160	160		program proyecto1;
161	161
162	162		{$mode objfpc}{$H+}
163	163
164	164		uses
165	165		SysUtils;
166	166
167	167		begin
168	168		WriteLn(GetAppConfigDir(True));
169	169		WriteLn(GetAppConfigDir(False));
170	170		WriteLn(GetAppConfigFile(True));
171	171		WriteLn(GetAppConfigFile(False));
172	172		end.
173	173		```
174	174
175	175		La salida en un sistema GNU/Linux con FPC 2.2.2. Tenga en cuenta que el uso de true está libre de errores, ya están fijadas en 2.2.3:
176	176
177	177		/etc/project1/
178	178		/home/user/.config/project1/
179	179		/etc/project1.cfg
180	180		/home/user/.config/project1.cfg
181	181
182	182		Se puede notar que los archivos de configuración global se almacenan en el directorio /etc y las configuraciones locales se almacenan en una carpeta oculta en el directorio inicial (home) del usuario. Los directorios cuyo nombre comienzan con un punto (.) están ocultos en Linux. Puedes crear un directorio en la ubicación que devuelve GetAppConfigDir y luego almacenar los archivos de configuración allí.
183	183
184	184		El resultado en Windows XP con FPC 2.2.4 + :
185	185
186	186		C:\Documents and Settings\All Users\Application Data\project1\
187	187		C:\Documents and Settings\user\Local Settings\Application Data\project1
188	188		C:\Documents and Settings\All Users\Application Data\project1\project1.cfg
189	189		C:\Documents and Settings\user\Local Settings\Application Data\project1\project1.cfg
190	190
191	191		Tenga en cuenta que antes de FPC 2.2.4 la función usaba el directorio del ejecutable para almacenar las configuraciones globales en Windows.
192	192
193	193		El resultado en Windows 98 con FPC 2.2.0:
194	194
195	195		C:\Program Files\PROJECT1
196	196		C:\Windows\Local Settings\Application Data\PROJECT1
197	197		C:\Program Files\PROJECT1\PROJECT1.cfg
198	198		C:\Windows\Local Settings\Application Data\PROJECT1\PROJECT1.cfg
199	199
200	200		El resultado en Mac OS X con FPC 2.2.0:
201	201
202	202		/etc
203	203		/Users/user/.config/project1
204	204		/etc/project1.cfg
205	205		/Users/user/.config/project1/project1.cfg
206	206
207	207		Nota: El uso de UPX interfiere con el uso de las funciones GetAppConfigDir y GetAppConfigFile.
208	208
209	209		Nota: En la mayoría de los casos los archivos de configuración son archivos de preferencias, que deben ser archivos XML con la terminación .plist y se almacenará en /Library/Preferences o en ~/Library/Preferences con nombres tomados del campo "identificador de paquete" en el Info.plist del paquete de aplicaciones. Utilizando las llamadas CFPreference de Carbon... es probablemente la forma más fácil de crear estos archivos de configuración .config en el directorio del Usuario son una violación de las líneas guía de programación.
210	210
211	211		### Archivos de datos y recursos
212	212
213	213		Una pregunta muy común es donde almacenar los archivos de datos que una aplicación puede necesitar, como imágenes, música, archivos XML, archivos de bases de datos, archivos de ayuda, etc. Desafortunadamente no hay funciones multi-plataforma para obtener la mejor localización para buscar archivos de datos. La solución es implementar de forma diferente en cada plataforma usando IFDEFs.
214	214
215	215		En Windows, simplemente puedes asumir que los archivos están en el mismo directorio que el ejecutable, o en una posición relativa al mismo.
216	216
217	217		En la mayoría de los sistemas operativos tipo Unix(como Linux, BSDs, solaris, etc), los archivos de datos están situados en posiciones fijas, que pueden ser algo como: /usr/share/app_name o /opt/app_name.
218	218
219	219		La mayoría de programas se ejecutarán sin privilegios de administrador y por lo tanto un programa multi-plataforma deberá almacenar los archivos de datos en un lugar donde siempre tenga permiso para leerlos, pero no necesariamente para modificarlos, y los archivos de configuración en lugares donde tenga además permiso para escribir en ellos.
220	220
221	221		Mac OS X es una excepción entre los sistemas operativos tipo UNIX. Aquí, la mejor manera de implementar aplicaciones es utilizar un paquete de aplicaciones, que incluye todos los archivos que la aplicación va a necesitar. Así, los archivos de recursos deben estar dentro del paquete, por lo que se puede mover y seguir trabajando normalmente. Tienes que usar llamadas a la API CoreFoundation para localizar el paquete.
222	222
223	223		#### Ejemplo
224	224
225	225		Esta sección presenta una solución particular para el caso en que en Windows los archivos de datos están en el mismo directorio que el ejecutable (o en un directorio relativo a este, tal que MiDirectorio + 'datos' + SeparadorRuta + 'miArchivo.datos'), y en *nix están en un directorio que se lee de un archivo de configuración. Si no existe el archivo de configuración o este no contiene información, entonces la constante ('/usr/share/myapp/') se utiliza como el directorio predeterminado.
226	226
227	227		El archivo de configuración se localiza con la función GetAppConfigFile de la RTL de Free Pascal.
228	228
229	229		A continuación se muestra una unidad completa que puedes utilizar en tus aplicaciones.
230	230
231	231		``` pascal
232	232		unit appsettings;
233	233
234	234		interface
235	235
236	236		{$ifdef fpc}
237	237		{$mode delphi}{$H+}
238	238		{$endif}
239	239
240	240		uses
241	241		Classes, SysUtils, Forms, IniFiles, constants;
242	242
243	243		type
244	244
245	245		{ TConfigurations }
246	246
247	247		TConfigurations = class(TObject)
248	248		private
249	249		function GetResourcesPath: string;
250	250		public
251	251		{otros ajustes serán campos aquí}
252	252		ConfigFilePath: string;
253	253		ResourcesPath: string;
254	254		constructor Create;
255	255		destructor Destroy; override;
256	256		procedure ReadFromFile(Sender: TObject);
257	257		procedure Save(Sender: TObject);
258	258		end;
259	259
260	260		var
261	261		vConfigurations: TConfigurations;
262	262
263	263		implementation
264	264
265	265		{$IFDEF Win32}
266	266		uses
267	267		Windows;
268	268		{$ENDIF}
269	269		{$ifdef Darwin}
270	270		uses
271	271		MacOSAll;
272	272		{$endif}
273	273
274	274		const
275	275		DefaultDirectory = '/usr/share/myapp/';
276	276
277	277		SectionGeneral = 'General';
278	278		SectionUnix = 'UNIX';
279	279
280	280		IdentResourcesPath = 'ResourcesPath';
281	281
282	282		{ TConfigurations }
283	283
284	284		constructor TConfigurations.Create;
285	285		begin
286	286		{$ifdef win32}
287	287		ConfigFilePath := ExtractFilePath(Application.EXEName) + 'myapp.ini';
288	288		{$endif}
289	289		{$ifdef Unix}
290	290		ConfigFilePath := GetAppConfigFile(False) + '.conf';
291	291		{$endif}
292	292
293	293		ResourcePath := GetResourcesPath();
294	294
295	295		ReadFromFile(nil);
296	296		end;
297	297
298	298		destructor TConfigurations.Destroy;
299	299		begin
300	300		Save(nil);
301	301
302	302		inherited Destroy;
303	303		end;
304	304
305	305		procedure TConfigurations.Save(Sender: TObject);
306	306		var
307	307		MyFile: TIniFile;
308	308		begin
309	309		MyFile := TIniFile.Create(ConfigFilePath);
310	310		try
311	311		MyFile.WriteString(SectionUnix, IdentResourcesPath, ResourcesPath);
312	312		finally
313	313		MyFile.Free;
314	314		end;
315	315		end;
316	316
317	317		procedure TConfigurations.ReadFromFile(Sender: TObject);
318	318		var
319	319		MyFile: TIniFile;
320	320		begin
321	321		MyFile := TIniFile.Create(ConfigFilePath);
322	322		try
323	323		// Aquí puedes leer más información del archivo de configuración
324	324
325	325		{$ifdef Win32}
326	326		ResourcesPath := MyFile.ReadString(SectionUnix, IdentResourcesPath,
327	327		ExtractFilePath(Application.EXEName));
328	328		{$else}
329	329		{$ifndef darwin}
330	330		ResourcesPath := MyFile.ReadString(SectionUnix, IdentResourcesPath,
331	331		DefaultDirectory);
332	332		{$endif}
333	333		{$endif}
334	334		finally
335	335		MyFile.Free;
336	336		end;
337	337		end;
338	338
339	339		function TConfigurations.GetResourcesPath(): string;
340	340		begin
341	341		{$ifdef Darwin}
342	342		var
343	343		pathRef: CFURLRef;
344	344		pathCFStr: CFStringRef;
345	345		pathStr: shortstring;
346	346		{$endif}
347	347		begin
348	348		{$ifdef UNIX}
349	349		{$ifdef Darwin}
350	350		pathRef := CFBundleCopyBundleURL(CFBundleGetMainBundle());
351	351		pathCFStr := CFURLCopyFileSystemPath(pathRef, kCFURLPOSIXPathStyle);
352	352		CFStringGetPascalString(pathCFStr, @pathStr, 255, CFStringGetSystemEncoding());
353	353		CFRelease(pathRef);
354	354		CFRelease(pathCFStr);
355	355
356	356		Result := pathStr + BundleResourcesDirectory;
357	357		{$else}
358	358		Result := DefaultDirectory;
359	359		{$endif}
360	360		{$endif}
361	361
362	362		{$ifdef Windows}
363	363		Result := ExtractFilePath(Application.EXEName);
364	364		{$endif}
365	365		end;
366	366
367	367		initialization
368	368
369	369		vConfigurations := TConfigurations.Create;
370	370
371	371		finalization
372	372
373	373		FreeAndNil(vTranslations);
374	374
375	375		end.
376	376		```
377	377
378	378		y este es un ejemplo de utilización de esta unidad:
379	379
380	380		``` pascal
381	381		bmp := TBitmap.Create
382	382		try
383	383		bmp.LoadFromFile(vConfigurations.ResourcesPath + 'MiMapaBits.bmp');
384	384		finally
385	385		bmp.Free;
386	386		end;
387	387		```
388	388
389	389		### 32/64 bits
390	390
391	391		#### Conversión de Punteros / Enteros
392	392
393	393		Un Puntero en 64 bits necesita 8 bytes en vez de los 4 sobre 32 bits. El tipo 'Integer' sigue siendo por compatibilidad de 32 bits en todas las plataformas. Esto significa que no se puede convertir a los punteros en números enteros y a la inversa (no son compatibles). FPC define dos tipos para realizar esto: PtrInt y PtrUInt. PtrInt es un entero con signo de 32 bits en plataformas de 32 bits y de 64 bits en las plataformas de 64 bits. Lo mismo para el número entero PtrUInt, pero sin signo en este caso.
394	394
395	395		Utilización en código que debe trabajar con Delphi y FPC:
396	396
397	397		``` pascal
398	398		{$IFNDEF FPC}
399	399		type
400	400		PtrInt = integer;
401	401		PtrUInt = cardinal;
402	402		{$ENDIF}
403	403		```
404	404
405	405		Sustituye todos las ocurrecias de integer(unPuntero_o_unObjeto) por PtrInt(unPuntero_o_unObjeto).
406	406
407	407		### Formato de multiByte
408	408
409	409		Las plataformas de Intel son little endian, eso significa que el byte menos significativo va primero. Por ejemplo, los dos bytes del word \$1234 se almacenan como \$34 \$12 en estos sistemas. En los sistemas big endian como el IBM powerpc los dos bytes de \$1234 se almacenan como \$12 \$34. La diferencia es importante al leer los archivos creados en otros sistemas.
410	410
411	411		Usaremos esto en código que trabaje en ambos sistemas:
412	412
413	413		``` pascal
414	414		{$IFDEF ENDIAN_BIG}
415	415		...
416	416		{$ELSE}
417	417		...
418	418		{$ENDIF}
419	419		```
420	420
421	421		Lo contrario es `{$IFDEF ENDIAN_LITTLE}`.
422	422
423	423		La unidad system proporciona muchas funciones de conversión, como de SwapEndian, BEtoN (big endian a endian actual),LEtoN (little endian a endian actual), NtoBE (endian actual a big endian) y NtoLE (endian actual a little endian).
424	424
425	425		#### Libc y otras unidades especiales
426	426
427	427		Evita las unidades heredadas cómo "oldlinux" y "libc" no admitidos fuera de linux/i386.
428	428
429	429		#### Ensamblador
430	430
431	431		Evita el ensamblador.
432	432
433	433		#### Directivas del compilador
434	434
435	435		``` pascal
436	436		{$ifdef CPU32}
437	437		...escribe aquí código para procesadores de 32 bits
438	438		{$ENDIF}
439	439		{$ifdef CPU64}
440	440		...escribe aquí código para procesadores de 64 bits
441	441		{$ENDIF}
442	442		```
443	443
444	444		### Proyectos, paquetes y rutas de búsqueda
445	445
446	446		Los proyectos y paquetes Lazarus se diseñan para múltiples plataformas. Normalmente copiamos el proyecto y los paquetes necesarios en otra máquina y los compilamos. No es necesario crear un proyecto para cada plataforma.
447	447
448	448		Algunos consejos para lograrlo
449	449
450	450		El compilador crea por cada unidad un archivo .ppu con el mismo nombre. Este .ppu puede ser utilizado por otros proyectos y paquetes. El fuente de la unidad (por ejemplo, Unidad1.pas) no debe ser compartida. Simplemente dale al compilador un directorio de salida para la unidad donde crear los archivos .ppu. El IDE realiza esto de forma predeterminada, así que nada que hacer por aquí.
451	451
452	452		Cada archivo de unidad debe ser parte de un proyecto o paquete. Si un archivo de unidad es para uso exclusivo de un único proyecto, agrégalo a ese proyecto. En caso contrario, agrégalo a un paquete. Si aún no has creado un paquete para tus unidades para compartir, mira aquí: [[Lazarus Packages/es\|Creación de un paquete para las unidades comunes]]
453	453
454	454		Cada proyecto y paquete debe tener directorios disjuntos, no deben compartir directorios. De lo contrario deberás ser un experto en el arte de rutas de búsqueda del compilador. Si no eres un experto o si otras personas que puedan utilizar tu proyecto o paquete no son expertos: no compartir directorios entre los proyectos / paquetes.
455	455
456	456		#### Unidades específicas de plataforma
457	457
458	458		Por ejemplo la unidad wintricks.pas sólo debe usarse en Windows. En la sección uses pon:
459	459
460	460		``` pascal
461	461		uses
462	462		Classes, SysUtils
463	463		{$IFDEF Windows}
464	464		,WinTricks
465	465		{$ENDIF}
466	466		;
467	467		```
468	468
469	469		Si la unidad es parte de un paquete, también debes seleccionar la unidad en el editor de paquetes y desactivar casilla de verificación de Usar unidad.
470	470
471	471		#### Rutas de búsqueda específicas de plataforma
472	472
473	473		Al desarrollar para varias plataformas y acceder al sistema operativo directamente, entonces rápidamente te cansarás de las interminables construcciones IFDEF. Una solución que se utiliza a menudo en FPC y los fuentes de Lazarus es utilizar los archivos de inclusión. Crear un directorio por cada plataforma. Por ejemplo win32, Linux, BSD, Darwin. Poner en cada directorio un archivo de inclusión con el mismo nombre. A continuación, utilice una macro en la ruta de inclusión. La unidad puede utilizar una directiva include normal.
474	474
475	475		Un ejemplo para un archivo de inclusión para cada LCL widgetset:
476	476
477	477		Crear un archivo para cada conjunto de controles para los quieras dar soporte:
478	478
479	479		``` pascal
480	480		win32/example.inc
481	481		gtk/example.inc
482	482		gtk2/example.inc
483	483		carbon/example.inc
484	484		```
485	485
486	486		No es necesario añadir los archivos al paquete o proyecto. Agrega la ruta de búsqueda `$(LCLWidgetType)` a las opciones del compilador de su paquete o proyecto.
487	487
488	488		En tu unidad utiliza la directiva: `{$I example.inc}`
489	489
490	490		Estas son algunas macros y valores comunes útiles:
491	491
492	492		- LCLWidgetType: win32, gtk, gtk2, qt, carbon, fpgui, nogui
493	493		- TargetOS: linux, win32, win64, wince, freebsd, netbsd, openbsd, darwin (y más)
494	494		- TargetCPU: i386, x86_64, arm, powerpc, sparc
495	495		- SrcOS: win, unix
496	496
497	497		Puedes utilizar la macro `$Env()` para acceder a variables de entorno.
498	498
499	499		Y por supuesto puedes usar combinaciones. Por ejemplo, la LCL usa:
500	500
501		-	~~`$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS);$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)`~~
	501	+	```text
	502	+	$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS);$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)
	503	+	```
502	504
503	505		Ver aquí la lista completa de macros:: [[IDE Macros in paths and filenames/es\|Macros del IDE en rutas y nombres de archivo]]
504	506
505	507		#### Rutas específicas de búsqueda de Máquina / Usuario
506	508
507	509		Por ejemplo tienes dos máquinas windows stan y oliver. En stan tus unidades están en C:\unidades y en oliver tus unidades están in D:\ruta. Las unidades del paquete MaterialCompartido están en C:\unidades\MaterialCompartido.lpk en stan y en D:\ruta\MaterialCompartido en oliver.
508	510
509	511		Una vez que abras el archivo .lpk en el IDE o con lazbuild, la ruta se almacena automáticamente en los archivos de configuración (packagefiles.xml).
510	512
511	513		Al compilar un proyecto que requiere el paquete MaterialCompartido, el IDE y lazbuild saben dónde está. Así que no se necesita configuración.
512	514
513	515		Si quieres desplegar un paquete sobre varias máquina o para todos los usuarios de una máquina (por ejemplo, las compartidas para estudiantes), entonces puedes agregar un archivo .lpl en el directorio de fuentes de Lazarus. Ver empaquetado / vínculos globales para los ejemplos.
514	516
515	517		### Diferencias [locales](http://es.wikipedia.org/wiki/Locale)
516	518
517	519		Algunas funciones de Free Pascal, como StrToFloat se comportan de manera diferente dependiendo de la [localización](http://es.wikipedia.org/wiki/Internacionalización_y_localización) actual. Por ejemplo, en EE.UU. el separador decimal es por lo general ".", Pero en Europa y muchos países de América del Sur es ",". Este puede ser un problema ya que a veces se desea tener esta funciones se comporten de una manera fija, independientemente de la localización. En las secciones siguientes se explica cómo hacerlo
518	520
519	521		#### StrToFloat
520	522
521	523		Un nuevo conjunto de opciones de formato que establece un separador decimal fijo se pueden crear con el siguiente código:
522	524
523	525		``` pascal
524	526		var
525	527		FPointSeparator, FCommaSeparator: TFormatSettings;
526	528		begin
527	529		// Ajustes del formato para convertir una cadena a coma flotante
528	530		FPointSeparator := DefaultFormatSettings;
529	531		FPointSeparator.DecimalSeparator := '.';
530	532		FPointSeparator.ThousandSeparator := '#';// desactivar el separador de miles
531	533		FCommaSeparator := DefaultFormatSettings;
532	534		FCommaSeparator.DecimalSeparator := ',';
533	535		FCommaSeparator.ThousandSeparator := '#';// desactivar el separador de miles
534	536		```
535	537
536	538		Por último puedes utilizar esta configuración de formato al llamar a StrToFloat, así:
537	539
538	540		``` pascal
539	541		// Esta función funciona como StrToFloat, pero trata dos posibles separadores decimales
540	542		// Esto evitará una excepción cuando el formato de cadena no coincide con la configuración local
541	543		function AnSemantico.StringToFloat(AStr: string): Double;
542	544		begin
543	545		if Pos('.', AStr) > 0 then Result := StrToFloat(AStr, FPointSeparator)
544	546		else Result := StrToFloat(AStr, FCommaSeparator);
545	547		end;
546	548		```
547	549
548	550		## Cuestiones específicas de Windows
549	551
550	552		### Funciones API de Windows
551	553
552	554		Muchos programas de Windows utilizan la API de Windows ampliamente. En las aplicaciones multiplataforma las funciones de la Win API en la unidad windows no deben utilizarse, o deberían estar encerradas por una compilación condicional (v.g. {\$IFDEF MSWINDOWS} ).
553	555
554	556		Por suerte muchas funciones comunes del API de Windows están incorporadas de manera multiplataforma en la unidad LCLIntf. Esto puede ser una solución para los programas que dependen fuertemente de la API de Windows, aunque la mejor solución es reemplazar estas llamadas con la verdadera componentes multiplataforma de la LCL. Por ejemplo, reemplazar las llamadas a funciones de dibujo GDI con llamadas a los métodos de un objeto TCanvas.
555	557
556	558		La detección de códgigos de (v.g. en eventos KeyUp) es portable: ver [[LCL Key Handling/es\|Gestión de teclas de la LCL]].
557	559
558	560		### En Unix no hay directorio de aplicación
559	561
560	562		Muchos programadores utilizan ExtractFilePath(ParamStr(0)) o Application.ExeName para obtener la ubicación del ejecutable, y luego buscar los archivos necesarios para la ejecución del programa (imágenes, archivos XML, archivos de base de datos, etc.) basandose en la ubicación del ejecutable. Esto en Unix está equivocado. La cadena ParamStr(0) puede contener un directorio que no sea el del ejecutable, y que también variar según con interpretes de comandos diferentes (sh, bash, etc.).
561	563
562	564		Incluso si Application.ExeName puede conocer el directorio donde el ejecutable está, el archivo puede ser un enlace simbólico, por lo que se obtendrá el directorio del enlace en su lugar (dependiendo de la versión del núcleo Linux, se obtendrá el directorio del enlace o del programa binario mismo)
563	565
564	566		Para evitar esto, lea las secciones sobre [[Multiplatform Programming Guide/es\|Archivos de configuración]] y [[Multiplatform Programming Guide/es\|Archivos de datos y recursos]].
565	567
566	568		## Prescindir de la automatización COM de Windows
567	569
568	570		En Windows la automatización COM es una potente forma no sólo para utilizar otros programa remotamente, sino también para permitir que otros programas utilizar tu programa. Con Delphi puedes hacer un programa, tanto cliente como servidor de automatización, lo que significa que puede manipular otros programas y, a su vez ser manipulado por otros programas. Para ejemplos ver [[Office Automation/es\|Usar automatización COM para interaccionar con OpenOffice y Microsoft Office]].
569	571
570	572		Por desgracia, la automatización COM no está disponible en OS X y Linux. Sin embargo, puedes simular algunas de las funcionalidades de automatización en OS X usando AppleScript.
571	573
572	574		AppleScript es similar a la automatización en cierto modo. Por ejemplo, puedes escribir secuencias de comandos que manipulan otros programas. He aquí un ejemplo muy simple de AppleScript que comienza NeoOffice (la versión para Mac de OpenOffice.org):
573	575
574		-	~~` tell application "NeoOffice"`\~~
575		-	~~` launch`\~~
576		-	~~` end tell`~~
	576	+	``` pascal
	577	+	tell application "NeoOffice"
	578	+	launch
	579	+	end tell
	580	+	```
577	581
578	582		Una aplicación que está diseñada para ser manipulada por AppleScript ofrece un "diccionario" de las clases y comandos que se pueden utilizar con la aplicación, similar a las clases de un servidor de Automatización Windows. Sin embargo, incluso aplicaciones como NeoOffice que no proporcionan un diccionario responderá a los comandos "launch", "activate" y "quit". AppleScript puede ejecutarse desde el Finder de OS X o desde el Editor de secuencias o incluso convertirse en una aplicación que puedes colocar en el panel al igual que cualquier aplicación. También puede ejecutar AppleScript desde su programa, como en este ejemplo:
579	583
580		-	~~` Shell('myscript.applescript');`~~
	584	+	```text
	585	+	Shell('myscript.applescript');
	586	+	```
581	587
582	588		Se supone que la secuencia de comandos se encuentra en el archivo indicado. También puedes ejecutar secuencias de comandos al vuelo a partir de tu aplicación utilizando el comando OsaScript de OS X:
583	589
584		-	~~` Shell('osascript -e '#39'tell application "NeoOffice"'#39 +`\~~
585		-	~~` ' -e '#39'launch'#39' -e '#39'end tell'#39);`\~~
586		-	~~` {Note use of #39 to single-quote the parameters}`~~
	590	+	``` pascal
	591	+	Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
	592	+	' -e '#39'launch'#39' -e '#39'end tell'#39);
	593	+	{Note use of #39 to single-quote the parameters}
	594	+	```
587	595
588	596		Sin embargo, estos ejemplos son sólo el equivalente del comando Open:
589	597
590		-	~~` Shell('open -a NeoOffice');`~~
	598	+	```text
	599	+	Shell('open -a NeoOffice');
	600	+	```
591	601
592	602		Del mismo modo, en OS X se puede emular la línea de comandos de Windows para iniciar un navegador web e iniciar un cliente de correo electrónico con:
593	603
594		-	~~` fpsystem('open -a safari "`[`http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html`](http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html)`"');`~~
	604	+	```text
	605	+	fpsystem('open -a safari "http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html"');
	606	+	```
595	607
596	608		y
597	609
598		-	~~` fpsystem('open -a mail "`[`mailto:ss4200@invalid.org`](mailto:ss4200@invalid.org)`"');`~~
	610	+	```text
	611	+	fpsystem('open -a mail "mailto:ss4200@invalid.org"');
	612	+	```
599	613
600	614		que asume, con bastante certeza, que un sistema OS X tendrá Safari y la aplicación de correo instalados. Por supuesto, no se deben hacer presunciones como esta, y para los dos ejemplos anteriores, puedes, de hecho sólo basarte en OS X para hacer lo correcto y elegir el navegador y el cliente de correo electrónico predeterminados del usuario si en su lugar utilizas estas variaciones:
601	615
602		-	~~` fpsystem('open "`[`http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html`](http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html)`"');`~~
	616	+	```text
	617	+	fpsystem('open "http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html"');
	618	+	```
603	619
604	620		y
605	621
606		-	~~` fpsystem('open "`[`mailto:ss4200@invalid.org`](mailto:ss4200@invalid.org)`"');`~~
	622	+	```text
	623	+	fpsystem('open "mailto:ss4200@invalid.org"');
	624	+	```
607	625
608	626		No olvides incluir la unidad de Unix en la cláusula uses si utilizas `fpsystem` o `shell` (indistintamente).
609	627
610	628		La potencia real de AppleScript es manejar de forma remota los programas para crear o abrir documentos y automatizar otras actividades. Cuánto se puede hacer con un programa depende de qué tan extenso es su diccionario AppleScript (si lo tiene). Por ejemplo, los programas de Office de Microsoft X no son muy útiles con AppleScript, mientras que los nuevos programas de Office 2004 han reescrito por completo diccionarios para AppleScript que son comparables en muchos aspectos con lo que está disponible a través de los servidores de automatización del Office en Windows.
611	629
612	630		Mientras que las secuencias de comandos Linux permiten sofisticadas líneas de ordenes, el tipo de secuencias de comandos se limita a lo que se puede pasar a un programa en la línea de parámetros. No hay una forma única y unificada para acceder a las clases y comandos internos de un programa Linux en la forma en que se hace a través de la automatización de Windows y AppleScript de OS X. Sin embargo, cada entorno de escritorio (GNOME / KDE) y los entornos de aplicaciones a menudo proporcionan estos métodos de comunicación entre procesos. En GNOME hay que ver los componentes Bonobo. KDE tiene el marco KParts y DCOP. OpenOffice tiene una plataforma neutral de la API para el control remoto de las aplicaciones (SDK OpenOffice); aunque probablemente tendrás que escribir código de unión en otro lenguaje que tenga enlaces (como Python) para utilizarlo. Además, algunas aplicaciones tienen "modos de servidor" activados por las opciones especiales de línea de comandos que les permiten ser controladas desde otro proceso. También es posible (Borland lo hizo con el visor de documentos de Kylix) para "integrar" una ventana de aplicación X de nivel superior en otra utilizando XReparentWindow (creo).
613	631
614	632		Al igual que con Windows, muchos programas de OS X y Linux se componen de múltiples archivos de librería (extensiones .Dylib y .so). A veces, estas librerías están diseñadas para que también podamos utilizarlas en los programas que escribamos. Si bien esto es una manera de añadir algunas funcionalidades de un programa externo en nuestro programa, en realidad no es la mismo que ejecutar y manipular el propio programa externo. En cambio, tu programa se enlaza a la librería del programa externo y la usa de manera similar a cualquier otra librería de programación.
615	633
616	634		## See Also
617	635
618	636		- ~~<http://www.midnightbeach.com/jon/pubs/Kylix.html>~~ <http://www.midnightbeach.com/KylixForDelphiProgrammers.html> A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.
619	637		- <http://www.stack.nl/~marcov/porting.pdf> A guide for writing portable source code, mainly between different compilers.
620	638
621	639		---
622	640		From the Free Pascal wiki, page "Multiplatform Programming Guide/es", as it stood on 2020-02-20 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).
623	641		Category: Castellano
624	642		Category: Español

Back to history