Em 13/07/2019 às 11:09, pwseo disse:

@Earendil010102,

Vamos por partes:

Não percebo qual o motivo para os parâmetros argc e argv estarem relacionados com a execução «em modo debug». Se o teu código não depende dos argumentos passados na linha de comandos, não são necessárias essas variáveis. Outro pormenor: em C, dizer main() é diferente de main(void); o primeiro indica que main aceita um número indefinido de argumentos, o segundo indica que main não aceita argumentos (em C++ não é assim).

Relativamente ao fflush(stdin), não só não é a melhor maneira de limpar o buffer, é precisamente um dos erros mais conhecidos e documentados pela comunidade que programa em C. O comportamento de fflush(stdin) é indefinido segundo o próprio standard, o que significa que cada compilador é livre de fazer o que quiser com isso. Por exemplo no meu sistema, essa linha não funciona porque o GCC assim o escolheu.

A forma correcta de limpar o buffer é ler o seu conteúdo através de chamadas a getchar() até que seja devolvido um '\n' ou até que o input seja esgotado (EOF). Aqui fica uma função que faz precisamente isso (poderia ser abreviada, mas assim percebe-se melhor a sua intenção):

void clear_stdin(void)
{
        int c;
        do {
                c = getchar();
        } while (c != '\n' && c != EOF);
}

Apenas a título de curiosidade, fiz dois exemplos no Ideone.com onde podemos ver o comportamento de um determinado programa que aceita um número e uma letra e os devolve ao utilizador; esta versão utiliza fflush(stdin) para limpar o buffer, e esta versão utiliza a função clear_stdin() acima. Como podes ver, a versão que utiliza fflush(stdin) não limpa o buffer correctamente, e como resultado a «letra» lida é a tecla RETURN, que se reflecte no output (uma mudança de linha entre as aspas).

Em relação aos restantes pontos, acho que seria interessante (e benéfico para ti) revisitar o código após entregar o trabalho. Desta forma poderás decidir que aspectos deverias melhorar, nomeadamente a tal separação do código em funções diferentes. A longo prazo, esta será uma das capacidades mais importantes a desenvolver, uma vez que a complexidade do código aumenta muito rapidamente com o seu tamanho; é fulcral desenvolver código correcto, compacto e legível que interaja de uma forma simples e explícita com o restante projecto.

Testei seu código, mas não sei se fiz da maneira correta. Vou anexá-lo para dizer o que acha.

#include <stdlib.h>
#include <stdio.h>
void clear_stdin(void)
{
        int c;
        do {
                c = getchar();
        } while (c != '\n' && c != EOF);
}

int main() {
	char n[30];
	printf("digite uma letra: ");
	scanf("%s", n);
	clear_stdin();
	return(0);
}

@pwseo, testei com o gets no lugar do scanf mas não funcionou. Para ler caractere simples usando o scanf("%c"), também funcionou.

Eu tive o mesmo problema e segui as instruções neste site (para mac) para desactivar o IPv6

Tive o mesmo problema e bastou desactivar o IPv6 e ficou tudo a funcionar 

A primeira coisa a fazeres é

pip install --upgrade pip

Tenta depois fazeres o que querias.

Bom dia,

Estou com um problema grave e não consigo encontrar solução:

Temos um programa em VB6 instalado em várias empresas que de repente após as ultimas atualizações do windows 10 (1903 18362.239), passou a dar erro quando se abrem forms que contenham o control MSHFlexGrid.

O erro aponta para o control ListView no ficheiro MSCOMCTL.OCX, Já pesquisei em tudo que é forum e embora encontre muitas soluções continuo com o problema.

Já tentei voltar a registar o OCX e reinstalar a aplicação.

O erro apenas aparece aparece quando o windows 10 faz a atualização para esta versão, em versões anteriores não existe problema algum.

O VB 6 (SP6) que estou a utilizar tem a versão VBA: Retail 60.9782

https://drive.google.com/file/d/11FlSj1iv2IAmJdHN0A_hjFJryqPKoO1U/view?usp=sharing

Olá.

Acabei de formatar meu PC e formatar a bruxaria que fiz na minha rede há 2 anos, na altura consegui colocar o pip a funcionar.

Agora pip não funciona, sempre faz isso por exemplo: http://prntscr.com/oeu2w2

Eu já mudei o meu DNS para o google, mas o problema persiste.Eu sei que o website está on porque se eu usar uma random VPS ele funciona! Alguma ideia de ccomo resolver?

On 7/12/2019 at 5:07 PM, HappyHippyHippo said:

respondendo sucintamente à questão essencial do tópico : não

o meu problema é com o uso do termo "objectivo secundário" ... secundário ? uma função que tem mais do que um objectivo ?

Ehhh ... Sorry. Não deixei isso muito claro. Aqui vai um código completo para melhor entendimento:

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <ncurses.h>

struct art_properties{

    int art;
    int quote;
    int art_color;
};

static void init_scr(void){

    if(initscr()==NULL){

        fprintf(stderr, "[X] - initscr() == NULL!\n");

        exit(EXIT_FAILURE);
    }

    if(has_colors()!=TRUE){

        endwin();

        fprintf(stderr, "[X] - Your terminal does not suport colors!\n");

        exit(EXIT_FAILURE);

    }else{

        int bkg_color;

        signal(SIGINT, SIG_IGN);
        signal(SIGTSTP, SIG_IGN);

        cbreak();
        noecho();
        keypad(stdscr, TRUE);

        start_color();

        if(use_default_colors()==OK){

            bkg_color=-1;

        }else{

            bkg_color=COLOR_BLACK;
        }

        init_pair(RED, COLOR_RED, bkg_color);
        init_pair(BLUE, COLOR_BLUE, bkg_color);
        init_pair(CYAN, COLOR_CYAN, bkg_color);
        init_pair(GREEN, COLOR_GREEN, bkg_color);
        init_pair(WHITE, COLOR_WHITE, bkg_color);
        init_pair(YELLOW, COLOR_YELLOW, bkg_color);
        init_pair(MAGENTA, COLOR_MAGENTA, bkg_color);

        refresh();
    }
}

static void handler(int num){

    clear();
    endwin();
    init_scr();
}

static int resize(void){

    struct sigaction new_action;
    struct sigaction old_action;

    new_action.sa_flags=0;
    new_action.sa_handler=handler;

    sigemptyset(&new_action.sa_mask);
    sigaction(SIGWINCH, &new_action, &old_action);

    return getmaxy(stdscr);
}

static size_t count_rows(const char *file_path){

    ssize_t rows=0;
    FILE *file=fopen(file_path, "r");

    if(file!=NULL){

        while(!feof(file)){

            if(fgetc(file)=='\n'){

                rows++;
            }
        }

        fclose(file);

    }else{

        rows=1;
    }

    return rows;
}

static struct art_properties *print_art(int y, struct art_properties *properties){

    struct art_properties aux;
    FILE *art_file=NULL, *quote_file=NULL;

    size_t i=0;
    char row_content[1025], str_quote[1025];

    const char *arts[]={"arts/art_001.txt", "arts/art_002.txt",
                        "arts/art_003.txt", "arts/art_004.txt",
                        "arts/art_005.txt", "arts/art_006.txt",
                        "arts/art_007.txt", "arts/art_008.txt",
                        "arts/art_009.txt", "arts/art_010.txt"};

    if(properties==NULL){

        srand(time(NULL));

        aux.art=rand()%9;
        aux.art_color=1+(rand()%7);
        aux.quote=1+(rand()%count_rows("quotes.txt"));

        properties=malloc(sizeof(struct art_properties));

        memcpy(properties, &aux, sizeof(struct art_properties));

    }else{

        memcpy(&aux, properties, sizeof(struct art_properties));
    }

    attron(COLOR_PAIR(aux.art_color) | A_BOLD);

    art_file=fopen(arts[aux.art], "r");

    if(art_file!=NULL){

        for(i=0; i<count_rows(arts[aux.art]); i++){

            fgets(row_content, 1025, art_file);

            mvprintw(y+i, 1, "%s", row_content);
        }

        fclose(art_file);
    }

    quote_file=fopen("quotes.txt", "r");

    if(quote_file!=NULL){

        for(int i=0; i!=aux.quote; i++){

            fgets(str_quote, 1025, quote_file);
        }

        mvprintw(y+2+i, 1, "[GANADO QUOTE] - %s", str_quote);

        fclose(quote_file);
    
    }else{

        mvprintw(y+2+i, 1, "[GANADO QUOTE] - \"Te voy a matar!\"");
    }

    attroff(COLOR_PAIR(aux.art_color) | A_BOLD);

    return properties;
}

static void free_art(struct art_properties **ptr){

    free(*ptr);
    *ptr=NULL;
}

int main(void){

    int key, y;
    struct art_properties *properties=NULL;

    init_scr();

    y=getmaxy(stdscr);

    do{

        properties=print_art(1, properties);

        attron(COLOR_PAIR(YELLOW) | A_BOLD);
        mvprintw(y-1, 1, "[i] - Press Enter key to quit");
        attroff(COLOR_PAIR(YELLOW) | A_BOLD);

        key=getch();
        y=resize();

    }while(key!=10);

    free_art(&properties);

    endwin();

    return EXIT_SUCCESS;
}

Na real ela não tem extamente um objetivo "segundário" e sim um único propósito, que é imprimir uma arte no terminal e manter as suas propriedades (cor, quote, arte) mesmo quando a janela for redimensionada.

@Earendil010102,

Vamos por partes:

Não percebo qual o motivo para os parâmetros argc e argv estarem relacionados com a execução «em modo debug». Se o teu código não depende dos argumentos passados na linha de comandos, não são necessárias essas variáveis. Outro pormenor: em C, dizer main() é diferente de main(void); o primeiro indica que main aceita um número indefinido de argumentos, o segundo indica que main não aceita argumentos (em C++ não é assim).

Relativamente ao fflush(stdin), não só não é a melhor maneira de limpar o buffer, é precisamente um dos erros mais conhecidos e documentados pela comunidade que programa em C. O comportamento de fflush(stdin) é indefinido segundo o próprio standard, o que significa que cada compilador é livre de fazer o que quiser com isso. Por exemplo no meu sistema, essa linha não funciona porque o GCC assim o escolheu.

A forma correcta de limpar o buffer é ler o seu conteúdo através de chamadas a getchar() até que seja devolvido um '\n' ou até que o input seja esgotado (EOF). Aqui fica uma função que faz precisamente isso (poderia ser abreviada, mas assim percebe-se melhor a sua intenção):

void clear_stdin(void)
{
        int c;
        do {
                c = getchar();
        } while (c != '\n' && c != EOF);
}

Apenas a título de curiosidade, fiz dois exemplos no Ideone.com onde podemos ver o comportamento de um determinado programa que aceita um número e uma letra e os devolve ao utilizador; esta versão utiliza fflush(stdin) para limpar o buffer, e esta versão utiliza a função clear_stdin() acima. Como podes ver, a versão que utiliza fflush(stdin) não limpa o buffer correctamente, e como resultado a «letra» lida é a tecla RETURN, que se reflecte no output (uma mudança de linha entre as aspas).

Em relação aos restantes pontos, acho que seria interessante (e benéfico para ti) revisitar o código após entregar o trabalho. Desta forma poderás decidir que aspectos deverias melhorar, nomeadamente a tal separação do código em funções diferentes. A longo prazo, esta será uma das capacidades mais importantes a desenvolver, uma vez que a complexidade do código aumenta muito rapidamente com o seu tamanho; é fulcral desenvolver código correcto, compacto e legível que interaja de uma forma simples e explícita com o restante projecto.

kkk, perdão!

Era Apache que eu queria dizer.

Mas a dúvida permanece!

14 horas atrás, Vitor Pereira disse:

Não entendo bem a questão,

de qualquer das formas e se não estás a tratar o IVA no Recibo ( não é IVA de Caixa ), o Recibo apenas tem de mencionar o valor a pagar e os documentos a que se refere, e não interessa se o pagamento se refere a parte ou á totalidade da Fatura

Vitor também não entendi bem a questão do @pedrokins, mas eu refiro nos Recibos o IVA, basta que por exemplo os Recibos tenham Retenção na Fonte, Foi-me aconselhado, não só pelos meus colegas CCs na empresa, como pelo pessoal da AT. 

Compreendo que uma coisa é o Fluxo Financeiro e outra o Comercial, ainda assim, também compreendo, que apareçam as "contas" certinhas no Recibo. 

O que faço nestes casos, é não deixar trabalhar com parciais. Se a FT tem retenção, o Recibo só sai na Totalidade com Retenção e com a Tabela de IVA.(não é necessário na contabilidade?) , é que a Retenção só é feita no Pagamento, logo no Recibo ou numa FR. 

Em 01/07/2019 às 11:22, chesser disse:

Obrigado CrominhO.

Só é pena terem esperado para o dia 28 de Junho para esclarecer que iam prolongar o prazo. Tenho uma questão no e-balcão a perguntar isso mesmo há mais de mês e meio e ainda continuo sem resposta. Adiar o prazo era de esperar, mas podiam ter esclarecido isto há muito mais tempo.

Era realmente importante que esclarecessem mesmo todas as dúvidas até dia 1 de Outubro, porque para tudo estar a funcionar nos clientes, como previsto, a 1 de Janeiro de 2020, vamos ter muito que trabalhar. Se se atrasarem, mais uma vez não vão ter de adiar os prazos.

O ponto 4 do Despacho do Secretário de Estado é um assunto que já aqui falamos algumas vezes. Vamos lá ver o que os srs da AT vão desenvolver, agora que foram instados a intensificar os trabalhos para que, com a maior brevidade possível, disponibilizem a tal aplicação gratuita.

@chesser acho que voltou a estar hoje em debate na AR o famoso decreto, ou pelo menos parte dele. O que me faz  confusão, é que supostamente ontem era o ultimo debate e hoje saem noticias que estiveram novamente a debater o decreto. O ideal era anularem por completo a confusão que ali está expressa e refazerem, se é que isso é possível... São muitos pontos para alterar 😕 

nenhuma delas é PHP