Gerar documentos individuais em word na mala direta.

 

O código abaixo gera documentos individuais, em docx, para cada um dos registros em um documento do Word com mala direta (Correspondência). O campo "Escola" deve existir na mala direta, pois será o nome do arquivo docx que será mesclado individualmente (apenas com os dados da referida linha). O nome da Macro sugerido é "exp". 

Sub exp()

    Dim docOrig As Document

    Dim docNovo As Document

    Dim campoEscola As String

    Dim i As Integer

    Dim pastaDestino As String

    

    ' Define o documento principal como o ativo

    Set docOrig = ActiveDocument

    ' Certifique-se de que há uma mala direta configurada

    If docOrig.MailMerge.DataSource.RecordCount = 0 Then

        MsgBox "Nenhum registro encontrado na mala direta.", vbExclamation, "Erro"

        Exit Sub

    End If

    ' Define a pasta onde os arquivos serão salvos

    pastaDestino = docOrig.Path

    If pastaDestino = "" Then pastaDestino = Environ("USERPROFILE") & "\Documents"

    ' Percorre todos os registros da mala direta

    With docOrig.MailMerge

        For i = 1 To .DataSource.RecordCount

            ' Define o registro atual para a mala direta

            .DataSource.ActiveRecord = i

            

            ' Obtém o valor do campo "Escola"

            campoEscola = Trim(.DataSource.DataFields("Escola").Value)

            ' Substitui caracteres inválidos para nomes de arquivos

            campoEscola = Replace(campoEscola, "/", "-")

            campoEscola = Replace(campoEscola, "\", "-")

            campoEscola = Replace(campoEscola, ":", "-")

            campoEscola = Replace(campoEscola, "*", "-")

            campoEscola = Replace(campoEscola, "?", "-")

            campoEscola = Replace(campoEscola, """", "-")

            campoEscola = Replace(campoEscola, "<", "-")

            campoEscola = Replace(campoEscola, ">", "-")

            campoEscola = Replace(campoEscola, "|", "-")

            ' Verifica se o campo não está vazio

            If campoEscola <> "" Then

                ' Cria uma cópia do documento original apenas para o registro atual

                docOrig.Range.Copy

                ' Cria um novo documento e cola o conteúdo da cópia

                Set docNovo = Documents.Add

                docNovo.Range.Paste

                

                ' Salva o novo documento com o nome da Escola

                docNovo.SaveAs2 FileName:=pastaDestino & "\" & campoEscola & ".docx", FileFormat:=wdFormatDocumentDefault

                

                ' Fecha o novo documento

                docNovo.Close False

            End If

        Next i

    End With

    MsgBox "Documentos exportados com sucesso! Verifique a pasta: " & pastaDestino, vbInformation, "Concluído"

End Sub

Erros 4xx e 5xx: O Que São e Como Corrigir?

 Se você já navegou na internet e encontrou páginas com mensagens como "404 Not Found" ou "500 Internal Server Error", então já se deparou com os famosos erros 4xx e 5xx. Mas o que eles significam? Vamos entender melhor!

🔹 Erros 4xx – Problemas no Lado do Cliente

Os erros 4xx ocorrem quando há algo errado na solicitação feita pelo usuário. Isso pode ser um link quebrado, falta de permissões ou até um erro de digitação na URL.

Principais erros 4xx:

✅ 400 - Bad Request → A solicitação foi malformada ou contém dados inválidos.
✅ 401 - Unauthorized → O acesso exige autenticação.
✅ 403 - Forbidden → O servidor bloqueou o acesso ao recurso.
✅ 404 - Not Found → A página solicitada não existe ou foi removida.
✅ 405 - Method Not Allowed → O método HTTP utilizado (GET, POST, etc.) não é permitido.
✅ 408 - Request Timeout → O tempo para responder a solicitação expirou.
✅ 429 - Too Many Requests → Muitas requisições em um curto período.

🔹 Como corrigir?

• Verifique a URL digitada.
• Limpe o cache do navegador.
• Confira permissões de acesso, se aplicável.
• Caso seja um erro do seu site, corrija links quebrados e configure redirecionamentos.

---

🔹 Erros 5xx – Problemas no Servidor

Os erros 5xx indicam falhas do servidor ao processar uma solicitação válida.

Principais erros 5xx:

⚠ 500 - Internal Server Error → Erro genérico do servidor.
⚠ 502 - Bad Gateway → O servidor recebeu uma resposta inválida ao encaminhar a requisição.
⚠ 503 - Service Unavailable → O servidor está sobrecarregado ou em manutenção.
⚠ 504 - Gateway Timeout → O servidor não recebeu uma resposta a tempo de outro servidor.

🔹 Como corrigir?

• Tente recarregar a página após alguns minutos.
• Se for dono do site, revise os logs do servidor.
• Verifique configurações do .htaccess, banco de dados e plugins.
• Entre em contato com a hospedagem caso o problema persista.

---

Conclusão

Os erros 4xx e 5xx podem parecer assustadores, mas muitas vezes são fáceis de resolver. Se você gerencia um site, é essencial monitorá-los para garantir uma boa experiência para os visitantes.

Gostou do conteúdo? Compartilhe e deixe seu comentário! 🚀

Como Impedir que a Tela do Celular Desligue ou Bloqueie em um Aplicativo Android

Você já desenvolveu um aplicativo Android e se perguntou como evitar que a tela do celular desligue, hiberne ou ative a tela de bloqueio enquanto o app estiver aberto? Essa funcionalidade é especialmente útil para aplicativos de leitura, jogos ou monitoramento, onde o comportamento padrão de economia de energia pode atrapalhar a experiência do usuário.

Neste post, vou mostrar como implementar essa funcionalidade de maneira simples no Android Studio.

Mantendo a Tela Sempre Ativa no Android

A solução para impedir que a tela desligue é adicionar a flag FLAG_KEEP_SCREEN_ON na Activity do seu aplicativo. Essa configuração informa ao sistema operacional que, enquanto essa tela estiver ativa, ele deve evitar o bloqueio ou o desligamento automático.

Passo a Passo:

1. Abra o método onCreate() da sua Activity

   Adicione o seguinte código no método onCreate() para aplicar a configuração assim que a Activity for aberta:

   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_main);
   
       // Impede que a tela desligue enquanto esta Activity estiver visível
       getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
   }

2. Reverter o Comportamento (Opcional)

   Se for necessário permitir que o sistema volte a bloquear a tela quando o usuário sair da Activity, você pode limpar a configuração no método onDestroy():

   @Override
   protected void onDestroy() {
       super.onDestroy();
       getWindow().clearFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
   }

3. Testando o Aplicativo

   Compile e rode seu aplicativo. Verifique se a tela permanece ativa enquanto a Activity está visível, mesmo que você não interaja com o dispositivo.

Por Que Usar Esta Abordagem?

Essa solução é simples, eficaz e não exige permissões especiais no Android. É perfeita para aplicativos que exigem interação constante ou que não podem ser interrompidos pelo bloqueio da tela.

Cuidados Importantes:

• Evite deixar essa configuração ativa em todas as telas do aplicativo. Mantenha-a apenas onde realmente for necessário, para evitar consumo excessivo de bateria.
• Garanta que o comportamento volte ao normal quando o usuário sair do aplicativo.

Conclusão

Manter a tela sempre ativa em um aplicativo Android é uma tarefa fácil e pode melhorar muito a experiência do usuário em situações específicas. Com o uso de WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON, você garante que o sistema mantenha a tela ligada enquanto a Activity estiver visível.

Gostou da dica? Tem alguma dúvida ou sugestão? Deixe seu comentário abaixo!

Protegendo Arquivos Sensíveis em Servidores Compartilhados

Protegendo Arquivos Sensíveis em Servidores Compartilhados

Em servidores compartilhados, como os oferecidos pela Hostinger, é comum encontrar a pasta public_html, que é a raiz pública do site. Qualquer arquivo ou pasta dentro dela pode ser acessado via navegador, tornando-a inadequada para armazenar informações sensíveis, como chaves de acesso. Neste artigo, vou explicar como proteger esses dados e garantir a segurança do seu servidor.

1. Armazenando Arquivos Sensíveis no Diretório Privado

Arquivos importantes, como chaves de acesso, devem ser armazenados fora da pasta public_html, no diretório raiz do servidor. Por exemplo:

/home/username/
    private/          # Pasta para arquivos sensíveis
        key.txt       # Arquivo com chave de acesso
    public_html/      # Pasta pública do site
        index.php     # Arquivo principal do site
    

Exemplo de código PHP para acessar arquivos:

<?php
$keyPath = __DIR__ . '/../private/key.txt'; // Caminho relativo
$key = file_get_contents($keyPath);
echo "Chave carregada com sucesso.";
?>
    

2. Configurando Permissões Seguras

Para proteger os arquivos sensíveis, é essencial configurar as permissões corretamente:

• Pasta private: Use permissão 700 (somente o proprietário pode ler, escrever e executar).

  chmod 700 /home/username/private

• Arquivo de chave: Use permissão 600 (somente o proprietário pode ler e escrever).

  chmod 600 /home/username/private/key.txt

3. Configurando Permissões para public_html

A pasta public_html deve ter permissões configuradas para garantir que o servidor web possa acessá-la e exibir os arquivos publicamente, mas evitando que usuários não autorizados alterem seu conteúdo. As configurações típicas são:

• Código Octal: 750 ou 755.
• Quando usar 755: Se o servidor é configurado para que o usuário do servidor web (geralmente www-data, apache, ou nginx) esteja no grupo do proprietário da pasta.

  chmod 755 public_html

• Quando usar 750: Se o servidor web é executado pelo mesmo usuário proprietário da pasta.

  chmod 750 public_html

• Proteção adicional:
  • Certifique-se de que o proprietário da pasta seja o seu usuário de hospedagem.
  • O grupo deve incluir o usuário do servidor web:

    chown -R seu_usuario:grupo_do_servidor_web public_html

  • Arquivos dentro da public_html devem ter permissão 644:

    chmod 644 public_html/index.php

  • Arquivos JavaScript (.js) dentro da public_html também devem ter permissão 644:

    chmod 644 public_html/scripts/app.js

  • Pastas dentro da public_html devem ter permissão 755:

    chmod 755 public_html/css

4. Protegendo com .htaccess

Adicionar um arquivo .htaccess pode fornecer uma camada extra de proteção caso a pasta seja movida acidentalmente.

Order Allow,Deny
Deny from all
    

Ou, para versões modernas do Apache:

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
    

5. Permissões do .htaccess

Para o arquivo .htaccess dentro de public_html, use permissão 644. Isso garante que o servidor web possa lê-lo, mas evita alterações por usuários não autorizados:

chmod 644 /home/username/public_html/.htaccess

6. Resumo das Boas Práticas

• Armazene arquivos sensíveis fora de public_html.
• Configure permissões adequadas:
  • 700 para pastas privadas.
  • 600 para arquivos sensíveis.
  • 755 ou 750 para public_html.
  • 644 para arquivos dentro de public_html, como .htaccess, arquivos PHP e JavaScript.
• Use .htaccess para evitar acessos indevidos.
• Acesse arquivos com caminhos relativos ou absolutos no PHP.

Com essas práticas, você pode proteger seus arquivos sensíveis mesmo em um ambiente compartilhado. Se tiver dúvidas ou quiser compartilhar sua experiência, deixe um comentário abaixo! 😊