Como Se Explica?

[Paulo Nobre]

Imaginem um programa(por exemplo Contatos.exe) e um dat(Contatos.dat) que armazena os dados deste programa.

Abrindo o programa(clicando direto no contatos.exe) ele lê os dados do dat (se encontra na mesma pasta do contatos.exe) e mostra para o usuário. Nada demais.

Contato.exe e Contatos.dat se encontram dentro da pasta Contatos.

O problema é o seguinte: ao abrir este programa, o Contatos .exe através de outro(Por exemplo, chamado principal.exe), usando o comando

Caminho:=ExtractFilePath(Application.ExeName)+'\Executáveis\Contatos\Contatos.exe';

ShellExecute(0,'open',PChar(Caminho),nil,nil,SW_Shownormal);

ele dá um erro dizendo que não pode encontrar o Contatos.dat.

Se mudo o Contatos.dat de posição, da pasta onde se encontra o Contatos.exe, que é a pasta Contatos, para a pasta do executável que chama o programa, ou seja a pasta do principal.exe, ele funciona corretamente.

Como se explica isto?

Qual é a lógica?

Parece até uma questão de prova. não é?

Mas, é uma dúvida mesmo!

Paulo Nobre

[Graymalkin]

A questão é a "pasta de trabalho" (working directory). Quando você chama uma aplicação em outra pasta, por meio de uma função ou rotina, a pasta de trabalho dessa aplicação será a atual (e não a que a mesma está contida). Experimente fazer o seguinte antes de abrir:

pasta := ExtractFilePath(Application.ExeName)+'\Executáveis\Contatos\'
chdir(pasta);

E veja se dá certo.

Abraços,

Graymalkin

[Graymalkin]

Complementando a resposta acima, veja o protótipo da função ShellExecute:

HINSTANCE ShellExecute(

HWND hwnd, // handle to parent window

LPCTSTR lpOperation, // pointer to string that specifies operation to perform

LPCTSTR lpFile, // pointer to filename or folder name string

LPCTSTR lpParameters, // pointer to string that specifies executable-file parameters

LPCTSTR lpDirectory, // pointer to string that specifies default directory

INT nShowCmd // whether file is shown when opened

);

O parâmetro em negrito serve justamente para indicar o diretório de trabalho.

Abraços,

Graymalkin

[sem ideia p/ nick]

eu tenho uma coisa a dizer que talvez possa mudar muita coisa e ela e simples acho que voce errou numa / (barra) que colocou mais ... seguinte:

pasta := ExtractFilePath(Application.ExeName)+'\Executáveis\Contatos\'

chdir(pasta);

o camando

ExtractFilePath(Application.ExeName)

já retorna o endereço com uma barra no final então fica como se tive-se 2barras então deve dar erro...

confesso que não entendi seu prob direito.

agora eu vi esse erro no codigo, espero não ter falado bestera... (e que isso aconteceu comigo eu botava mais uma barra aki dava erru )

[Paulo Nobre]

Na mosca Graymalkin,

Fiz o que você falou e deu certo; o programa passou a abrir com o dat no mesmo diretório do exe. Aliás no tempo em que fazia programas em vb usava muito este chdir. No delphi quase nunca é necessário.

Vale observar que o problema só ocorreu por causa do arquivo dat sendo chamado pelo contato.exe. Se fosse apenas para chamar o contato.exe sem a necessidade do arquivo dat funcionaria.

Você saberia me dizer por que?

Como havia dito passando o dat para o diretório do programa que chama o contato.exe funciona.

Aí fica a questão; dat no diretório de quem chama ou dat no diretório do contato.exe com mais duas linhas de código.

Você acha que faz diferença?

Paulo Nobre

[Graymalkin]

Vale observar que o problema só ocorreu por causa do arquivo dat sendo chamado pelo contato.exe. Se fosse apenas para chamar o contato.exe sem a necessidade do arquivo dat funcionaria.

Você saberia me dizer por que?

Como havia dito passando o dat para o diretório do programa que chama o contato.exe funciona.

Exatamente porque no Contatos.exe você deve estar usando o caminho relativo do arquivo (por exemplo, "dados.dat") ao invés do caminho absoluto (por exemplo, "c:\pasta2\dados.dat"). Se o seu programa está sendo executado na pasta "c:\pasta" e você chama um programa qualquer que use um caminho relativo, você teria...

pasta atual (c:\pasta) + nome do arquivo

... o que resultaria, no caso, em "c:\pasta\dados.dat", por exemplo. Ou seja, quando especificamos um caminho relativo (ou seja, só o nome do arquivo, ou com os dirétorios "." e/ou "..") ele automaticamente "junta" com o diretório de trabalho atual.

Aí fica a questão; dat no diretório de quem chama ou dat no diretório do contato.exe com mais duas linhas de código.

Você acha que faz diferença?

Você tem três opções nesse caso (além da usada): ou o próprio programa (Contato.exe) muda o diretório de trabalho para o mesmo que está sendo executado (pela função chdir()); ou você usa o caminho absoluto do arquivo .DAT (ou seja pegando o diretório da aplicação (ExtractFilePath(Application.ExeName)) e juntando com 'dados.dat'; ou passa o diretório de trabalho do programa pelo parâmetro lpDirectory da função ShellExecute().

Abraços,

Graymalkin

[Paulo Nobre]

Você tem três opções nesse caso (além da usada): ou o próprio programa (Contato.exe) muda o diretório de trabalho para o mesmo que está sendo executado (pela função chdir()); ou você usa o caminho absoluto do arquivo .DAT (ou seja pegando o diretório da aplicação (ExtractFilePath(Application.ExeName)) e juntando com 'dados.dat'; ou passa o diretório de trabalho do programa pelo parâmetro lpDirectory da função ShellExecute().

Creio que a terceira é mais elegante.

Tudo entendido.

Obrigado pela aula Graymalkin.

Abraços

Paulo Nobre

[Graymalkin]

Você tem três opções nesse caso (além da usada): ou o próprio programa (Contato.exe) muda o diretório de trabalho para o mesmo que está sendo executado (pela função chdir()); ou você usa o caminho absoluto do arquivo .DAT (ou seja pegando o diretório da aplicação (ExtractFilePath(Application.ExeName)) e juntando com 'dados.dat'; ou passa o diretório de trabalho do programa pelo parâmetro lpDirectory da função ShellExecute().

Creio que a terceira é mais elegante.

Tudo entendido.

Obrigado pela aula Graymalkin.

Abraços

Paulo Nobre

Também acho. Se bem que em geral uso a segunda opção (formando o caminho absoluto).

Qualquer coisa, 'stamos aí.

Abraços,

Graymalkin