Página 1 de 1

Atualizações do Harbour 23-07-2025 HaruPDF

Enviado: 23 Jul 2025 21:26
por Itamar M. Lins Jr.
Olá!
Mudança do retorno do contador de página da hpdf

Código: Selecionar todos

2025-07-19 19:44 UTC+0200 Aleksander Czajczynski (hb fki.pl)
  * contrib/hbhpdf/core.c
    + HPDF_GetPageByIndex( hDoc, nIndex ) --> hPage / NIL
      suggested by Luigi Ferraris

  * contrib/hbhpdf/tests/harupdf.prg
    + test the above (disabled by default)

  * README.md
    * updated CI badge(s) to GitHub Actions - they also cover
      the strict compilation mode, definitions are currently
      located in the same file as normal

    ! cleaned up links, mostly in tools section, some were
      broken, for others switched to https where applicable

    * mention HB_CCPREFIX= support for clang

  * contrib/hbdoc/hbdoc.prg
  * contrib/hbformat/utils/hbformat.prg
  * contrib/hbnetio/utils/hbnetio/hbnetio.prg
  * package/harbour.mft
  * package/harbour.rc
  * src/compiler/hbusage.c
  * utils/hbi18n/hbi18n.prg
  * utils/hbtest/hbtest.prg
    * bumped copyright year to 2025
Interessante é o arquivo harbour.rc como é.
Olhando do Harbour para melhorar os nossos!

Código: Selecionar todos

/* Copyright 2011 Viktor Szakats (vszakats.net/harbour) */

#include "hbver.h"

#define HB_MACRO2STRING( macro )       HB_MACRO2STRING_( macro )
#define HB_MACRO2STRING_( macro )      #macro

#define HB_VER_PRODUCTVERSION          HB_VER_MAJOR,HB_VER_MINOR,HB_VER_RELEASE,0
#define HB_VER_PRODUCTVERSION_STR      HB_MACRO2STRING( HB_VER_MAJOR ) "." HB_MACRO2STRING( HB_VER_MINOR ) "." HB_MACRO2STRING( HB_VER_RELEASE ) HB_VER_STATUS "\0"
#define HB_VER_FILEVERSION             HB_VER_PRODUCTVERSION
#define HB_VER_FILEVERSION_STR         HB_VER_PRODUCTVERSION_STR

#define HB_NAME                        "Harbour\0"
#define HB_COPYRIGHT                   "Copyright \xA9 1999-2025 (see application banner)\0"

/* Version info */

#include <winver.h>

VS_VERSION_INFO VERSIONINFO
FILEVERSION    HB_VER_FILEVERSION
PRODUCTVERSION HB_VER_PRODUCTVERSION
FILEFLAGSMASK  VS_FFI_FILEFLAGSMASK
FILEFLAGS      0
FILEOS         VOS__WINDOWS32
FILETYPE       VFT_APP
BEGIN
   BLOCK "StringFileInfo"
   BEGIN
      /* LANGUAGE: US English ENCODING: Windows-1250 (0x04E2) */
      BLOCK "040904B0"
      BEGIN
         VALUE "Comments",         "See COPYING.txt for licensing terms.\0"
         VALUE "CompanyName",      HB_NAME
         VALUE "FileDescription",  HB_NAME
         VALUE "FileVersion",      HB_VER_FILEVERSION_STR
         VALUE "LegalCopyright",   HB_COPYRIGHT
         VALUE "ProductName",      HB_NAME
         VALUE "ProductVersion",   HB_VER_PRODUCTVERSION_STR
      END
   END

   BLOCK "VarFileInfo"
   BEGIN
      /* LANGUAGE: US English ENCODING: UNICODE (0x4B0) */
      VALUE "Translation", 0x409, 0x4B0
   END
END

/* Preparation for manifest */

/* Not using predefined Windows macros here, because some C compilers
   will fail badly with their own definitions (f.e. pocc) and/or their
   own Windows headers. [vszakats] */
#define __HB_CREATEPROCESS_MANIFEST_RESOURCE_ID 1
#define __HB_RT_MANIFEST                        24

Saudações,
Itamar M. Lins Jr.

Atualizações do Harbour 23-07-2025 HaruPDF

Enviado: 24 Jul 2025 15:52
por JoséQuintas
Eu vi sobre manifest pouco antes do harbour 3.4 fixar isso.
Acredito que foi até depois do meu comentário.
Os dois principais que vi foram da common control, e direitos de usuário.
O resto acrescentei por acrescentar, nem sei se precisa.

A Microsoft colocou uma espécie de bloqueio nos controles.
Se não liberar o "recurso a mais", ele não é usado.

Na GTWVG, a tooltip não estava funcionando, só funcionava depois de colocar isso no manifest.
Também o button com imagem+texto.
este bloco

Código: Selecionar todos

	<dependency>
		<dependentAssembly>
			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
            processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
		</dependentAssembly>
	</dependency>
Quando pesquisei também vi que se não colocar uso limitado, assume igual administrador, e isso requer coisas a mais.
este bloco

Código: Selecionar todos

		<security>
			<requestedPrivileges>
				<requestedExecutionLevel level="asInvoker" uiAccess="false" />
			</requestedPrivileges>
		</security>
o resto, coloquei por colocar.

Também dizia que pra rodar igual administrador o certificado seria obrigatório, e outras coisas mais.
Nunca mais olhei sobre isso.

Tem aquilo de compatibilidade, algo como ajudar o Windows a decidir o que fazer.
É mostrar em quais versões windows ele funciona.

Completo:

Código: Selecionar todos

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
   <assemblyIdentity name="JoseQuintas" processorArchitecture="x86" version="0.0.0.0" type="win32" />
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
		<security>
			<requestedPrivileges>
				<requestedExecutionLevel level="asInvoker" uiAccess="false" />
			</requestedPrivileges>
		</security>
	</trustInfo>
   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
         <!-- Windows 10 -->
         <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
         <!-- Windows 8.1 -->
         <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
         <!-- Windows 8 -->
         <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
         <!-- Windows 7 -->
         <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
         <!-- Windows Vista and Windows Server 2008 R2 -->
         <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
         <!-- Windows XP ignores this section -->
      </application>
   </compatibility>
	<dependency>
		<dependentAssembly>
			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
            processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
		</dependentAssembly>
	</dependency>
</assembly>
Isso acima crio como "exe.manifest"
Embutido tanto faz o nome, o nome não vai ser usado.
Pode ser usado EXTERNO, criando com o mesmo nome do EXE, tipo teste.exe, teste.exe.manifest

Já no RC, é aquilo de autor/nome/versão/etc.
Meu build.ch tem definição de versão, atualizo automático pelo meu intermediário ao compilar.

Também vi que AppIcon seria o nome default do ícone usado para o EXE, usado principalmente pelo mingw, mas parece valer pra todos

Código: Selecionar todos

#include "build.ch"

1 VERSIONINFO
  FILEVERSION JOSEQUINTAS_VERSAO_RC
  BEGIN
     BLOCK "StringFileInfo"
     BEGIN
        BLOCK "040904E4"
        BEGIN
            VALUE "CompanyName"      , "JPA TECNOLOGIA LTDA"
            VALUE "FileDescription"  , "JPA Integrado"
            VALUE "FileVersion"      , JOSEQUINTAS_VERSAO
            VALUE "LegalCopyright"   , "José M C Quintas"
            VALUE "LegalTrademarks"  , "José M C Quintas"
            VALUE "OriginalFilename" , "JPA.EXE"
            VALUE "ProductName"      , "JPA"
            VALUE "ProductVersion"   , JOSEQUINTAS_VERSAO
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x0416, 1252
    END
END

#define RT_MANIFEST 24
#define APP_MANIFEST 1

APP_MANIFEST RT_MANIFEST "resource\\exe.manifest"

AppIcon          ICON     "ico\\icoJPA.ico"
Uma coisa interessante é sobre o PATH.
Se colocar "/" só mingw reconhece. \\ todos reconhecem.
Barra invertida indica pra aceitar o próximo caractere como estiver, \\ equivale a uma única barra.

Daí pra frente, são só os resources tradicionais.

Descobri que pra aceitar DIALOG embutida em resources, pra mingw precisa de um #include

Código: Selecionar todos

#include "afxres.h"
Na época que vi isso ainda testava MINGW, BCC e MSVC 2010
Do jeito acima funcionava nos três.

Quando percebi que MSVC dependia de RUN-TIME do Visual C 2010, e que ele deixou de ser padrão no Windows, abandonei Visual C.
Visual C da Microsoft SEMPRE depende de run-time.
O Windows vém só com uma única versão disso.
Depois a Microsoft inventou o run-time universal, o tal UCRT, mas me parece que deu no mesmo.
Não depende de um, mas depende do outro....
Se não depende de número de versão piorou...
O windows novo vai aceitar programa velho, mas o windows velho não vão aceitar programa novo.
Volta ao problema de antigamente: ferramenta Microsoft obrigando a atualizar tudo.

O problema de antigamente era algo desse tipo.
Os programas sempre atualizavam versão nova... e quando eles se tornavam velhos, instalavam coisa velha.

Atualizações do Harbour 23-07-2025 HaruPDF

Enviado: 24 Jul 2025 15:57
por JoséQuintas
Da harupdf cheguei a ver o usuário pedindo isso, mas é recurso não disponível na harupdf.
Foi feito um quebra galho.

Na NFE, CTE, etc. fiz de outro jeito, vou guardando as páginas em array, pra colocar a numeração no final.