Poucos conseguem treebox em page

[JoséQuintas]

Poucos fazem isso.

A princípio treebox parece só funcionar em WINDOW
Mas meu uso de FIVEWIN mostrou que algumas coisas são diferentes pra DIALOG.

Quando você cria WINDOW ela está lá.... o que precisa dela ela está lá....
Quando você cria DIALOG, ela só vai ser criada no final, não adianta enviar comando pra mexer na janela porque ela ainda não existe.

Ok até aqui ?
Solução:
Na Dialog precisa colocar mudanças de treeview no INIT da DIALOG.

Ok até aqui ?

Mas nessa imagem a dialog é do DEMOALL e não do exemplo.
E passo pro exemplo a TAB.
E com certeza mais de um exemplo vai precisar disso.

Pois é... tá funcionando.
Como fiz isso ?
Vai estar na hwgui.
Agora ajustar o outro exemplo de treebox.

[JoséQuintas]

EBA

Deu certo.

Cada exemplo vai colocando o init que precisar no demoall.

Muito bom quando dá certo.

Mas o visual continua ruim kkkkkkkkkk

[alxsts]

Olá!

O que é um TreeBox?

Conheço TreeView, como o mostrado na imagem acima, e disponível em várias linguagens e bibliotecas GUI.

[JoséQuintas]

Peguei do exemplo, chamaram de treebox.

Na hwgui é TREE

Mas foi bom avisar, mudar os nomes.

Acho que chamaram de treebox porque monta a caixa com o tree dentro.

Tô mudando tanto os nomes, uma vez a mais ou a menos não faz diferença. kkkk

Lembrando: além do nome aí, ele puxa o exemplo demotreebox.prg

[JoséQuintas]

Tá começando a ficar com visual melhor.
E a lista já ultrapassou o limite da tela, e isso porque tem sub-tabs, com mais de um exemplo.
Por exemplo, browse tem DBF, Array, e ADO.

[JoséQuintas]

Tava começando a dar trabalho, então parto logo pro automático....
Quando a gente define as variáveis direitinho....
Tive que usar um truque aqui, fazer o que....

cria a lista

Código: Selecionar todos

   MenuOption( "Browse" )
      MenuDrop()
      MenuOption( "1.Browse ADO",         { |o| DemoBrowseADO( .F., o ) } )
      MenuOption( "2.Browse Array",       { |o| DemoBrowseArray( .F., o ) } )
      MenuOption( "3.Browse DBF",         { |o| DemoBrowseDbf( .F., o ) } )
      MenuUndrop()
   MenuOption( "Button" )
      MenuDrop()
      MenuOption( "1.OwnerButton",        { |o| DemoOwner( .F., o ) } )
#ifdef __PLATFORM_WINDOWS
      MenuOption( "2.ShadeButton",        { |o| DemoShadeBtn( .F., o ) } )
#endif
      MenuUnDrop()
   MenuOption( "Checkbox",                { |o| DemoCheckbox( .F., o ) } )
   MenuOption( "Combobox",                { |o| DemoCombobox( .F., o ) } )
   MenuOption( "Date" )
      MenuDrop()
#ifdef __PLATFORM__WINDOWS
      MenuOption( "1.MonthCal",           { |o| DemoMonthCal( .F., o ) } )
#endif
      MenuOption( "DateSelect",           { |o| DemoDateSelect( .F., o ) } )
      MenuOption( "Alt.DPicker",          { |o| DemoAltDPicker( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Get" )
      MenuDrop()
      MenuOption( "1.DemoGet2",           { |o| DemoGet2( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Listbox" )
      MenuDrop()
      MenuOption( "1.Listbox Alt",        { |o| DemoListBoxSub( .F., o ) } )
      MenuUndrop()
   MenuOption( "Menu" )
      MenuDrop()
      MenuOption( "1.menu", ,    "demomenu.prg",    { |o| DemoMenu( .F., o ) } )
      MenuOption( "2.menuxml", , "demomenuxml.prg", { |o| DemoMenuXml( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Say" )
      MenuDrop()
      MenuOption( "1.DemoGet2",           { |o| DemoGet2( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Splitter" )
      MenuDrop()
      MenuOption( "1.Treeview",           { |o| DemoTreeview( .F., o, aInitList ) } )
      MenuOption( "2.XML Tree",           { |o| DemoXmlTree( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Tab" )
      MenuDrop()
      MenuOption( "1.Lenta",              { |o| DemoLenta( .F., o ) } )
      MenuOption( "2.Tab",                { |o| DemoTab( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Timer",                   { |o| DemoGet2( .F., o ) } )
   MenuOption( "Trackbar" )
      MenuDrop()
      MenuOption( "1.HTrack",             { |o| DemoHTrack( .F., o ) } )
      MenuUnDrop()
   MenuOption( "Treeview" )
      MenuDrop()
      MenuOption( "1.Treeview",           { |o| DemoTreeview( .F., o, aInitList ) } )
      MenuOption( "2.XML Tree",           { |o| DemoXmlTree( .F., o ) } )
      MenuUnDrop()
   MenuOption( "UpDown",                  { |o| DemoUpDown( .F., o ) } )
   MenuOption( "AppData",                 { |o| DemoDbfData( .F., o ) } )

Como a gente faz a tab? tab.... page... conteudo.... endpage....
Foi isso que fiz.
Mas sem recursividade, porque só vai ter dois níveis, e a de dentro tem tamanho diferente da de fora.

Código: Selecionar todos

   FOR EACH aOption IN aMenuOptions
      BEGIN PAGE aOption[ 1 ] OF oTab
      IF Len( aOption[ 2 ] ) == 0 // no other level
         IF ValType( aOption[ 3 ] ) == "B"
            Eval( aOption[ 3 ], oTab )
         ELSE
         ENDIF
      ELSE
         FOR EACH oTab2 IN { Nil } // to have unique otab2
            @ 30, 30 TAB oTab2 ITEMS {} SIZE 800, 500 OF oTab
            FOR EACH aOption2 IN aOption[ 2 ]
               BEGIN PAGE aOption2[ 1 ] OF oTab2
               IF ValType( aOption2[ 3 ] ) == "B"
                  Eval( aOption2[ 3 ], oTab2 )
               ELSE
               ENDIF
               END PAGE OF oTab2
            NEXT
         NEXT
      ENDIF
      END PAGE OF oTab
   NEXT

Falta só preencher o ELSE.
O ELSE é para os casos aonde não dá pra ficar na tab, como por exemplo mostrar menus.
Nesse caso é um button pra chamar o exemplo.

Agora mais fácil mexer nas opções.
E agora tá bem visível que chamo os exemplos individuais.
O programa com tudo junto é praticamente isso acima.

[JoséQuintas]

Pra quem se perdeu, é só olhar acima.
begin page... conteudo... endpage.

Qual vai ser o conteúdo?
Depende
- se tem subopções, começa outra tab, tudo de novo aí dentro.
- se tem codeblock, é executar
- caso contrário, o button que ainda não criei

Meu menu sempre foi assim.
É tudo questão de definir direito as variáveis, elas mesmas podem fazer o trabalho do que seria uma rotina extensa.

[JoséQuintas]

Aqui usei um truque não comum.
Esse FOR EACH oTab2 é só pra criar essa variável LOCAL dentro da rotina.
Sem isso, oTAB2 vai ficar mudando de valor dentro do codeblock, e vai rodar rotina errada.
Sim...
Voce cria o codeblock com oTab2, mas no for/next ela acabaria tendo outro conteúdo.
Voce cria pensando na rotina ZERO, mas quando executar vai ser a rotina CINCO.
Esse FOR/EACH faz com que seja uma variável oTab2 diferente a "cada rodada".
Mais simples do que dividir a rotina em funções.

[JoséQuintas]

Acabei de usar isto outra vez.

Tava ssim:

Código: Selecionar todos

Hwg_DefineMenuItem( fname, 1020+i, &( "{||NewItem("+LTrim(Str(i,2))+")}" ) )

Agora tá assim:

Código: Selecionar todos

FOR EACH nPos IN { i } // variable for codeblock
   Hwg_DefineMenuItem( fname, 1020 + i, { || NewItem( nPos ) } )
NEXT

Vantagem ?
Deu erro de não achar a função, porque alterei pra STATIC

É legal isso.

É princípio básico da programação
Definir tipo de variável e de função também.

O exemplo tem tudo que precisa.
Nenhuma outra rotina pode alterar o que ele usa.
E ele não altera nenhuma outra rotina.

Dá pra ir juntando exemplos, sem medo de ser feliz, até algum limite estourar kkkkk

Notas:

O uso de macro nesse exemplo foi justamente pra contornar o problema da variável em codeblock.
Mas falhou, porque não fez o mesmo com a função.
O FOR/EACH resolveu, de um jeito muito melhor, sem surpresas em run-time.

Voltei no assunto porque apareceu essa situação.
Nessa situação tem essa função chamada, que deu erro, e mostra outra vantagem do uso

[JoséQuintas]

E se precisar de mais de uma variável ?
FOR/EACH faz isso

Código: Selecionar todos

aCodeList := {}
FOR nCont = 1 TO 10
   FOR nCont2 - 1 TO 10
      FOR EACH a, b IN { nCont }, { nCont2 }
         AAdd( aCodeList, { || Calcula( a, b ) } )
      NEXT
   NEXT
NEXT
FOR EACH bCode IN aCodeList
   ? Eval( aCode )
NEXT

FUNCTION Calcula( a, b )
   ? a, b
   RETURN Nil

Só fazer isso com e sem FOR/EACH e vai ver a diferença.
Provavelmente sem FOR/EACH vai mostrar sempre 11, 11

[JoséQuintas]

Me veio na cabeça....

A IA mostraria algo assim ?
Acho que não.
Pra IA, FOR/EACH é pra outro uso.

[JoséQuintas]

EITA !!!!
A parte que poucos conhecem aumentou mais.

Código: Selecionar todos

   MenuOption( "MT-Experimental" )
      MenuDrop()
      MenuOption( "A All",  "MT A",             { || DlgMDI() } )
      MenuUnDrop()

Código: Selecionar todos

               BEGIN PAGE aOption2[ 1 ] OF oTabLevel2

               IF ValType( aOption2[ 3 ] ) == "C" // can't run on tabpage
                  IF Left( aOption2[ 3 ], 3 ) == "MT"
                     @ 30, 50 BUTTON "run " + aOption2[ 3 ] ;
                        SIZE 200, 24 ;
                        ON CLICK aOption2[ 4 ]
                  ELSE
                     @ 30, 50 BUTTON aOption2[ 3 ] ;
                        SIZE 200, 24 ;
                        ON CLICK { || hb_ThreadStart( { || hwg_InitProc(), Eval( aOption2[ 4 ] ) } ) }
                  ENDIF
               ELSE
                  Eval( aOption2[ 3 ], oTabLevel2 )
               ENDIF

               END PAGE OF oTabLevel2

Então... cria a tab page.

Se a opção for texto.... precisa ser separada , cria um button pra fazer a execução - é o caso de exemplo de menu

Mas se o texto começa com MT - multithread - o button vai executar em multithread. é o caso de exemplo MDI

Senão, se tudo ok, executa o exemplo, que é pra ele criar o visual dele dentro da tab.

Agora sim, tudo pode ficar no demoall, até exemplo que precisa ser WINDOW principal.

[JoséQuintas]

Infelizmente, alarme falso.
Caiu no mesmo problema de não poder usar Window.
Sem mais testes mt tão cedo.

Pro restante nem precisa, tá tudo rodando ao mesmo tempo em tabpage