Um problema comum para ser resolvidos em desktops \u00e9 que evitar que o usu\u00e1rio carregue o mesmo programa diversas vezes. Neste artigo, vamos entender melhor este tipo de problema.<\/p>\n\n\n\n
Quando um usu\u00e1rio n\u00e3o se apercebe, mas carrega mais uma vez um programa que j\u00e1 tem na mem\u00f3ria isso \u00e9 ruim em v\u00e1rios aspectos: (1) \u00e9 mais consumo de mem\u00f3ria e recursos desnecessariamente carregados; (2) isso \u00e9 um ruim especialmente quando uma conex\u00e3o com o banco de dados est\u00e1 envolvida, pois cada programa trar\u00e1 um contexto transacional que concorre\u00e1 com a outra inst\u00e2ncia do mesmo programa e se houver opera\u00e7\u00f5es bloqueantes, outros usu\u00e1rios e si mesmo poder\u00e3o ficar esperando indefinidamente pelo recurso ser liberado.<\/p>\n\n\n\n
Ent\u00e3o n\u00e3o h\u00e1 duvidas de que bloquear uma segunda inst\u00e2ncia do mesmo programa \u00e9 o correto a ser feito. H\u00e1 v\u00e1rios m\u00e9todos para isso, mas qual deles usar?<\/p>\n\n\n\n
Muitos programadores usam um m\u00e9todo bastante simples, observam se j\u00e1 h\u00e1 um programe.exe carregado e se positivo ent\u00e3o decide abortar a carga. Um problema nessa abordagem \u00e9 que se o sistema operacional que estamos executando o programa for multi-terminal ou multi-usu\u00e1rio ent\u00e3o outros usu\u00e1rios n\u00e3o conseguir\u00e3o carregar o mesmo programa. O que desejamos bloquear \u00e9 a duplicata advindo do mesmo usu\u00e1rio e n\u00e3o de usu\u00e1rios diferentes.<\/p>\n\n\n\n
Se a palavra “multi-terminal” lhe soou estranha, basta entender que computadores atuais podem permitir que v\u00e1rios usu\u00e1rios remotos possam acessar um computador central e dal\u00ed rodar seus programas. O Windows Terminal Server(RDS), TS Plus ou GoGlobal s\u00e3o exemplos de softwares populares que permitem transformar um Windows num ambiente multi-terminal para acessos locais ou remotos.<\/p>\n\n\n\n
Qualquer que seja a solu\u00e7\u00e3o, precisaremos lidar com o fato em que o mesmo programa.exe pode estar carregado em multiplas inst\u00e2ncias, apenas n\u00e3o devem ser do mesmo usu\u00e1rio. Isso \u00e9 imprescindivel para que seu programa possa funcionar em ambientes multi-usu\u00e1rio e multi-terminal.<\/p>\n\n\n\n
Uma outra abordagem que programadores costumam usar \u00e9 uma fun\u00e7\u00e3o da WinAPI intitulada FindWindow, ela basicamente procura por uma janela(classe) com um certo nome. Ela ir\u00e1 resolver o problema, mas tem dois problemas (1) custo da opera\u00e7\u00e3o, pois o Windows carrega muitos programas e logo tem muitas classes e o usu\u00e1rio pode vir a carregar muitos outros programas e ao submeter um FindWindow na raiz do desktop dele ent\u00e3o levar\u00e1 tempo consider\u00e1vel encontrar uma em espec\u00edfico e outros problema (2) \u00e9 que uma janela(classe) de um programa que n\u00e3o tem nada a ver com o seu tenha o mesmo nome e isso far\u00e1 com que o seu programa nunca seja executado sob esta situa\u00e7\u00e3o.<\/p>\n\n\n\n
Usando com o Delphi e o FreePascal podemos lidar com o problema usando MUTEX. MUTEX para efeito pr\u00e1tico \u00e9 similar a criar constantes no formato texto visiveis para outros programas enxergaem na mesma sess\u00e3o(desktop) do usu\u00e1rio, mas que apenas existe enquanto o programa que os criou ainda existir, quando o programa morre, estas constantes que o programa criou v\u00e3o embora tamb\u00e9m.<\/p>\n\n\n\n
A solu\u00e7\u00e3o portanto \u00e9 testar a existencia de um MUTEX com um nome de referencia – e em nosso exemplo vamos usar como referencia o titulo do formul\u00e1rio principal – e se ela existir ent\u00e3o n\u00e3o prosseguiremos porque consideraremos que j\u00e1 existe uma instancia do programa e opcionalmente talvez apresentemos uma mensagem de erro. <\/p>\n\n\n\n
Diferentemente no FindWindow, o MUTEX ser\u00e1 instantaneo. Isso resolver\u00e1 o problema porque cada execu\u00e7\u00e3o seguinte encontrar\u00e1 o nome de referencia. O bom dessa solu\u00e7\u00e3o \u00e9 que ela funcionar\u00e1 em ambientes multi-terminais e muulti-terminal por causa do comportamento do MUTEX.<\/p>\n\n\n\n
Mas \u00e9 poss\u00edvel acrescentar um bonus, caso o MUTEX seja detectado podemos usar o FindWindow para encontrar a instancia previamente carregada e restaur\u00e1-la para a tela, afinal talvez esteja minimizado e o usu\u00e1rio n\u00e3o conseguiu not\u00e1-lo. Aqui vai o alerta, lembre-se de que o FindWindow pode demorar ent\u00e3o s\u00f3 use-o no exemplo abaixo se a performance n\u00e3o for um quesito importante comparado a facilidade do programa se auto-expor.<\/p>\n\n\n\n
O codigo a seguir ficar\u00e1 no arquivo .dpr no caso de usarmos o Delphi ouu no arquivo .lpr no caso de estarmos programando em Lazarus+FPC, vamos ao c\u00f3digo:<\/p>\n\n\n\n
program Programa;\n\n(...)\n\nuses\n (...) \n Forms,\n Windows;\n\n{$R *.res}\n\nvar\n MutexHnd: Cardinal;\n Handle: HWND;\n sTitle:String;\nbegin\n \/\/ unit Windows \u00e9 requerida por causa do FindWindow, IsWindowVisible\n sTitle:='Meu Titulo'\n RequireDerivedFormResource:=True; \/\/ Lazarus+FPC only\n Application.Scaled:=True; \/\/ Lazarus+FPC Only\n\n MutexHnd := CreateMutex(nil, False, pChar(sTitle));\n If GetLastError = ERROR_ALREADY_EXISTS Then\n begin\n \/\/TfmPrincipal \u00e9 a classe do form principal e\n \/\/ 'Meu Titulo' \u00e9 o caption do form principal\n \/\/ N\u00e3o funcionar\u00e1 em tempo de design porque a janela(caption) que procuro\n \/\/ para todas as hipoteses testadas esta visivel por causa da IDE.\n Handle := FindWindow(nil, pChar(sTitle));\n if Handle <> 0 then\n begin\n \/\/Application.MessageBox(\n \/\/ pChar(sTitle+' j\u00e1 est\u00e1 em execu\u00e7\u00e3o, observe a bandeja do sistema.'+sLineBreak+\n \/\/ 'Se fez o logout nos ultimos instantes, '+\n \/\/ 'aguarde uns 60 segundos para carregar-me novamente.'),\n \/\/ pChar('Ops, j\u00e1 estou carregado:')\n \/\/ );\n if not IsWindowVisible(Handle) then\n ShowWindow(Handle, SW_RESTORE);\n SetForegroundWindow(Handle);\n Application.Terminate;\n end\n end\n else\n begin\n Application.Initialize;\n Application.Title:=sTitle;\n Application.ShowMainForm:=True; \/\/ Delphi only\n Application.MainFormOnTaskbar := True; \/\/ Delphi only\n Application.CreateForm(TfmPrincipal, fmPrincipal);\n fmPrincipal.Caption:=sTitle; \/\/ n\u00e3o mude o caption depois\n Application.Run;\n end;\nend. <\/pre><\/div>\n\n\n\nO c\u00f3digo acima \u00e9 justamente colocado no carregamento do projeto, isto \u00e9, no arquivo .dpr no caso do Delphi ou .lpr no caso do Lazarus+FPC.<\/p>\n\n\n\n
As linhas marcadas como ‘Delphi only’ dever\u00e3o ser removidas caso voc\u00ea esteja usando o Lazarus e as linhas comentadas como ‘Lazarus+fpc’ voc\u00ea as remove se estiver usando Delphi.<\/p>\n\n\n\n
CONCLUSION<\/h2>\n\n\n\n
Assim temos um c\u00f3digo plenamente funcional. Existem por a\u00ed outros c\u00f3digos diferentes, mas alguuns deles esbarram no problema comum j\u00e1 citado, n\u00e3o sabem lidar com ambientes multi-tarefas ou multi-usu\u00e1rios e o nosso codigo foi testado neste contexto.<\/p>","protected":false},"excerpt":{"rendered":"
Um problema comum para ser resolvidos em desktops \u00e9 que evitar que o usu\u00e1rio carregue o mesmo programa diversas vezes. Neste artigo, vamos entender melhor este tipo de problema. ENTENDENDO O PROBLEMA Quando um usu\u00e1rio n\u00e3o se apercebe, mas carrega mais uma vez um programa que j\u00e1 tem na mem\u00f3ria isso \u00e9 ruim em v\u00e1rios […]<\/p>\n","protected":false},"author":4,"featured_media":0,"parent":145,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"templates\/template-full-width.php","meta":{"footnotes":""},"class_list":["post-2299","page","type-page","status-publish","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t