Aqui eu também procurei de todas as formas possíveis e não consegui resolver, a única solução foi essa mesmo executar o Setup antes, e deixar o parâmetro lDisabeSetup do FWMsPrinter como falso mesmo. Queria muito uma solução mais coerente com o processo.
Uma coisa que eu pude observar é o seguinte: o sétimo parâmetro do New() da classe FWMsPrinter diz que pode receber um objeto do tipo FWPrintSetup, porém se passar o objeto nesse parâmetro daria a entender que deixando o quinto parâmetro lDisabeSetup como .F. o sistema deveria chamar esse objeto passado, só que isso não ocorre, ele cria um novo (ignorando totalmente o que foi passado) e acaba ficando travada a interface do usuário sem poder fechar. Se passar o FWPrintSetup e o parâmetro lDisabeSetup como .T., o sistema não faz nada.
Em resumo podemos fazer apenas de duas formas:
1) Criamos o objeto FWPrintSetup alimentamos como nossas configurações, chamamos para exibição ao usuário, e passamos todas as informações colhidas desse objeto para o FWMSPrinter (com o parâmetro lDisabeSetup :=.T. e o sétimo parâmetro NIL).
2) Chamamos a classe FWMSPrinter passando o parâmetro lDisabeSetup := .F. e o sétimo parâmetro NIL, assim a própria classe FWMSPrinter chama o Setup (sempre as mesmas configurações padrão dele).
Acho que é isso pessoal, fiz diversos testes aqui até chegar a estas conclusões, eu também sofro com essa comportamento contraintuitivo dessa classe FWMSPrinter. Infelizmente a documentação das duas classes no TDN (FWMSPrinter e FWPrintSetup) não explicam nada sobre esses comportamentos e como utilizar esses dois parâmetros na instanciação da classe FWMSPrinter.
Aqui fiz até uma classe customizada para encapsular todas esses pequenos tratamentos e simplificar meu código. (com tratamentos para salvar e recuperar os parâmetros e impressora selecionada pelo usuário, coisa que o padrão não tem nada implementado [MAS DEVERIA]).
