Arquivo de atalho nem sempre inicia quando a tecla de atalho é pressionada

Question

Na minha empresa, temos pequenas estações de trabalho ~ 13 polegadas com tela sensível ao toque. O sistema operacional é: Microsoft Windows Embedded Standard 6.1.7601 Service Pack 1 Build 7601
As estações de trabalho possuem 5 botões que podem ser mapeados para qualquer combinação de teclas. (exemplo ctrl+alt+shift+[any key on the keyboard] )

Existem dois programas que devem ser executados neles para que os funcionários possam trabalhar. Às vezes, os trabalhadores acidentalmente fecham um dos programas, então decidi obter uma solução para isso, já que eles não podem iniciar os programas sozinhos.

Então eu tenho:
- criou um arquivo de lote que, quando iniciado, verifica se os programas estão sendo executados; caso contrário, os inicia; - criou um atalho do arquivo de lote (em %appdata%\Microsoft\Windows\Start Menu\Programs como sugerido aqui );
- adicionada uma tecla de atalho (ctrl + alt + s);
- atribuiu um dos botões na estação de trabalho ao enlace de teclas.

Parecia uma boa ideia em teoria, mas na prática a atalho de teclado não estava funcionando corretamente.

Após a solução de problemas, percebi que um dos programas está causando o problema.
Vamos chamar os programas A e B . Quando B ou a área de trabalho está na frente, a combinação de teclas funciona corretamente e inicia o arquivo em lotes. A funciona em tela cheia. Então, quando a combinação de teclas é pressionada enquanto A está na frente, não funciona.
Então eu atribuí uma combinação de teclas alt + tab para outro botão, mas é aí que o problema entra em ação.

Se eu tiver pressionado anteriormente a combinação de teclas ctrl + alt + S enquanto A estava na frente, não funcionará depois mesmo depois que eu mudei para B ou para a área de trabalho.

O que torna mais interessante é que, se eu criar outra tecla de atalho em outro arquivo de atalho, digamos ctrl + alt + D e executá-lo depois que ctrl + alt + S parou de funcionar, ele corrige e ctrl + alt + S começa a funcionar novamente enquanto B ou a área de trabalho tem foco.

Tentei isso , não funcionou.
Red este fórum. Nenhuma solução.

Estou procurando uma solução / solução alternativa / outro método para resolver esse problema.

Eu não quero instalar nenhum programa de terceiros. No entanto, posso modificar as configurações e o registro, se necessário.

EDITAR:

O arquivo em lote

echo off
tasklist /FI "IMAGENAME eq progB.exe" 2>NUL | find /I /N "progB.exe">NUL
if "%ERRORLEVEL%"=="1" (
cd C:\<progB path>
start /MAX progB.exe

)

tasklist /FI "IMAGENAME eq progA.exe" 2>NUL | find /I /N "progA.exe">NUL
if "%ERRORLEVEL%"=="1" C:\<progA path>

exit

    

Answer 1

Uma solução de força bruta é programar a execução do arquivo de lote repetidamente a cada minuto. O objetivo é que, se os programas estiverem em execução, que esta verificação não será perceptível pelo usuário.

Infelizmente, nesses computadores lentos que executam o Windows Embedded Standard 6, tasklist e sua variante são muito lentos, então temos que encontrar outra mecanismo para verificar se os programas estão sendo executados. Felizmente, parece que a verificação da existência de um arquivo ainda é muito rápido.

O mecanismo que proponho é lançar os programas usando esta sintaxe:

prog 2 >> \path\to\lockfile

O parâmetro "2 > > file" significa que o arquivo de erro do prog é redirecionado para lockfile. Este arquivo, também chamado de stderr no Linux, normalmente nunca é escrito para pela maioria dos programas. Enquanto o programa está em execução, o arquivo é bloqueado e não pode ser excluído, pois está em uso. Se o programa for interrompido, o arquivo pode ou não existir, mas pode ser excluído.

Aqui está um exemplo de um script que verifica se um arquivo existe e pode ser excluído. Eu adicionei os comandos echo, úteis durante a depuração de um script.

@echo off
if exist \path\to\lockfile (
  echo lockfile exists
  del \path\to\lockfile
  if exist \path\to\lockfile (
    echo lockfile is locked - program is running
  ) else (
    echo lockfile was deleted - program is not running
    **launch program here**
  )
) else (
  echo lockfile doesn't exist - program is not running
  **launch program here**
)

Para fechar o programa sem iniciar automaticamente, como para manutenção, desabilitar o agendamento do arquivo em lotes.

Ou, se isso for demais, adicione outro arquivo chamado "maintenance" e verifique sua existência no arquivo de lote, não fazendo nada se ele existir. Exclua o arquivo quando a manutenção for finalizada.

Para testar, pode-se bloquear o arquivo por meio desse script em lote. Pressione qualquer tecla para parar:

pause 2 >> \path\to\lockfile

Referências:

• Redirecionamento e canais de E / S
• Um índice A-Z da linha de comando do Windows CMD

Answer 2

Sua abordagem para esse problema é única e parece próxima, mas está fugindo de você. Pensando no mesmo caminho que você seguiu até agora, aqui está uma oferta.

Se for seguro , o que você terá que completamente determinar, você pode optar por usar uma associação de chave para Alt + F4 nos aplicativos. Seria ainda melhor se você pudesse fazer uma combinação de Alt + Tab primeiro, depois Alt + F4. Teoricamente, você seria capaz de fechar os dois aplicativos e retornar para a área de trabalho pressionando essa tecla no máximo três vezes.

Isso o deixaria em uma posição em que você conhece o estado exato de ambos os aplicativos - não em execução. Usando uma versão redigida de sua ligação, você pode iniciar seus aplicativos (não há mais a necessidade de verificar se eles estão sendo executados).

Exemplo (ambos os aplicativos estão sendo executados):

• aplicativo A tem foco na janela
• [pressione a ligação] B tem foco e fecha, retornando o foco para A
• [press bind] desktop tem foco e nada se fecha
• [press bind] A tem foco e fecha

Exemplo 2 ( B foi fechado):

• desktop tem foco na janela
• [press bind] A (por exemplo) tem foco e fecha, retornando o foco para desktop

Como alternativa, você pode ter uma chave para fazer o Alt + Tab e outra para fazer o Alt + F4. Os usuários teriam que pressionar a tecla 1 , seguida da tecla 2 , para um total de 3 pressionamentos para cada botão.

Cabe a você determinar se Alt + F4ing seus aplicativos são seguros. Pode-se considerar que isso nunca será seguro, mas não é absolutamente seguro se seus aplicativos processam dados ativamente, processam dados com base em uma programação, têm uma conexão de banco de dados ativa, ect. Se as aplicações só executam suas funções quando um usuário intervém com uma solicitação, e Alt + F4ing em cada aplicativo não deixa nenhum dado ou bloqueio temporário, pode não haver conseqüência.

Como sempre, há mais de uma abordagem para o seu problema. Essa solução específica fica com o seu processo de pensamento inicial e o tema geral.