Thursday, February 28, 2008

Usando Temas do Windows em programas Delphi 5 e 6

Recentemente me deparei com um problema bem incômodo ao usar temas através do Theme Manager de Mike Lischke.
O maior problema foram os TBitBtn's que não eram desenhados de acordo com o tema do Windows pelo Theme Service. Procurei várias soluções e não encontrei nada, nem no FAQ da soft-gems. Depois de mais alguma pesquisa, finalmente descobri!
A causa e a solução do problema são relativamente simples:
O problema só ocorria em forms que continham TBitBtn e cujo Owner não era o objeto Application. Uso frequentemente diálogos chamando uma função de classe que cuida de sua criação e destruição da seguinte forma:

class function TMyDialog.Execute: boolean;
var
Dlg: TMyDialog;
begin
Dlg := TMyDialog.Create(nil);
try
Result := Dlg.ShowModal = mrOk;
finally
Dlg.Free;
end;
end;

Usado desta forma os TBitBtn's neste diálogo não serão desenhados de acordo com o tema do Windows. O melhor a fazer é substituir o código por:

class function TMyDialog.Execute: boolean;
var
Dlg: TMyDialog;
begin
Dlg := TMyDialog.Create(Application);
try
Result := Dlg.ShowModal = mrOk;
finally
Dlg.Free;
end;
end;

Neste caso o TBitBtn é desenhado corretamente!

Thursday, January 17, 2008

TIOBE index again!

Esta segue o link no blog do Marco Cantu. Como ele diz "está longe de ser científico" mas mostra bem o que está acontecendo! ;-)

http://blog.marcocantu.com/blog/delphi_tiobe_jan2008.html

Friday, January 11, 2008

Mais futurologia....

Entre meus colegas de trabalho sou reconhecido defensor do Delphi com relação a outras linguagens/IDE's. Hoje tive uma rápida conversa com um colega que me disse: "Lá para 2010 software nativo será como o DOS era para o Windows e rodará em modo de compatibilidade (mal e porcamente)".
Sendo assim teremos os seguintes "softwares" que rodarão "mal" e em "modo de compatibilidade":

- Todos os softwares servidores da M$ incluindo o SQL Server cujo core é 100% native code e deve ter um zilhão de linhas de C/C++ escritas!
- Aplicativos servidores da ORACLE, IBM...
- Java Virtual Machine
- .NET, FCL
- Todos os aplicativos MS-Windows - out of the box

Ou alguém acha que a ORACLE, por exemplo, irá reescrever os seus servidores de BD em VS.NET??? LOL!!!

O interessante é ver como a propaganda da MS é forte. Como é possível convencer tantos desenvolvedores que um software escrito para usar a API do sistema operacional pode ser forçado a rodar em "modo de compatibilidade" sendo que o próprio framework .NET da M$ usa exatamente a mesma API, da mesma forma???!!! Quem sabe o diagrama da arquitetura .NET ajude?

Talvez 90% dos desenvolvedores Windows que conheço precisem ler um pouco mais de informação e menos PROPAGANDA, tipo o site do Steve Trefethen AQUI.

Este camarada já passou longos anos na Borland e é um insider da M$. Então, com certeza, sabe muito mais o que fala do que os marketeiros da M$, é ou não é?

Saudações por hoje.

Unicode no Tiburon

O blog da CodeGear está bem agitado estes dias. Allen Bauer comandando! Tudo sobre Unicode no Tiburon:

http://blogs.codegear.com/abauer/2008/01/09/38845/

http://blogs.codegear.com/abauer/2008/01/09/38846/

http://blogs.codegear.com/abauer/2008/01/10/38847/

http://blogs.codegear.com/abauer/2008/01/11/38848/

O Allen fala em um dos posts: "Mudança pior aconteceu quando houve a transição de 16 bits para 32 bits, Delphi 1 para Delphi 2."

Isto é fato. Foi muito mais drástico do que agora. E mesmo assim, mais fácil do que se previa. Ao contrário da M$, que não teve a menor piedade dos desenvolvedores VB6, a Borland (CodeGear) sempre primou pela manutenção da compatibilidade.
Eu vivi esta experiência de transição de sistemas 16/32 bits e posso afirmar: Valeu cada hora de trabalho recodificando a aplicação.
E outra: "Não se pode fazer uma omelete sem quebrar os ovos", já dizia minha vovozinha - que Deus a tenha!

Tuesday, January 8, 2008

IIS e ASP.NET: +Erros no Deploy de WebServices

Mais alguns probleminhas com WebServices em ASP.NET no BDS 2006: Este pode tanto acontecer no deploy quanto no debug:

Unable to load type 'Global.TGlobal'.

ou em bom português

Não foi possível carregar o tipo 'Global.TGlobal'.

Vez por outra encontrei este erro quando tentei debugar o WebService rodando pelo IDE, usando o IIS, sendo que o diretório virtual no ISS foi criado no próprio IDE. Por default, o BDS cria uma pasta bin abaixo da pasta onde se encontra o projeto do WebService. Desta forma, ele "espera" que o assembly seja salvo nesta pasta bin.
Se não houver nenhuma configuração adicional do projeto, o assembly será salvo no mesmo diretório dos fontes, e neste caso poderá haver este erro.
Basta copiar, ou mover o assembly gerado para a subpasta bin e o aplicativo poderá ser debugado normalmente.
Convém alterar as opções do projeto direcionando o "Output dir" para esta subpasta bin.

IIS e ASP.NET: Erros no Deploy de WebServices

Criando aplicações ASP.NET no BDS 2006, me deparei com alguns erros no momento do deploy. Um deles foi:

"Server cannot access application directory "APP_DIR". The directory does not exist or is not accessible because of security settings.


Por incrível que pareça a mensagem de erro é de fato informativa, e é bem plausível que seja realmente permissão insuficiente para acessar o diretório da aplicação (APP_DIR). Logo de início dei permissões de leitura a "Everyone" (Todos) e a aplicação funcionou corretamente. Obviamente esta não é a solução ideal e de fato não é necessário conceder esta permissão tão abrangente. Basta conceder permissão de leitura na pasta da aplicação ao usuário [Machine_Name]\ASPNET, e voilá!


Ambiente de referência:
- Windows 2000 Server - SP4
- .NET Framework V 1.1.4322

Friday, January 4, 2008

Futuro do DataSnap

Conversa rápida com o John Kaster (CodeGear Internet Services Architect) no newsgroup da CG hoje:

Pergunta minha a ele: "Will DataSnap remain tied to COM?"

Resposta: "I think it's safe to answer "no" for this one. Steve (Shaughnessy) is definitely
looking at eliminating COM as a required technology DataSnap solution,
and what he has in mind is 100% feasible and achievable."
...
"What I want to see is "native" (supported by the respective
platform/language frameworks) interop among data operations, REST,
"skins", user ids, tagging, commenting, searching, and so on for all
these platforms."

Fiquei feliz! :-) O DataSnap precisa se livrar da infraestrutura COM para então alcançar outro patamar.

Agora é esperar a revisão do roadmap do Delphi que o Nick Rodges disse que sai até o fim do mes de Janeiro, e ficar de olho no que o Tiburon trará de novidade.