[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.axapta.programming

Check ckeckboxes automaticaly

babyto

2/18/2006 7:26:00 PM

Hi there i have in a form with 2 datagrids one with invoices and underneath a
grid showing the lines to each invoice. There is a checkbox infront of every
line and i would like when an invoice is checked, the corresponding lines
that are displayes below, to have their checkboxes automatically checked when
the check box of an invoice line is marked. Any idea how to implement
that?Thanks :)
3 Answers

David Pokluda

2/23/2006 4:42:00 PM

0

I would do the following (one of the following):

1. override click method for your parent (invoice) checkbox and from there
update database so that also checkboxes for child lines are checked.

2. override click method for your parent (invoice) checkbox and then check
all child checkboxes (iterate through your child grid):
childCheckbox.value(true);
childCheckbox.click();

I don't know if that's the good/right solution.

Regards,
David.

"babyto" <babyto@discussions.microsoft.com> wrote in message
news:D678361D-18D4-4020-A48E-E759CAE234DD@microsoft.com...
> Hi there i have in a form with 2 datagrids one with invoices and
> underneath a
> grid showing the lines to each invoice. There is a checkbox infront of
> every
> line and i would like when an invoice is checked, the corresponding lines
> that are displayes below, to have their checkboxes automatically checked
> when
> the check box of an invoice line is marked. Any idea how to implement
> that?Thanks :)


Francois Grieu

10/21/2009 5:08:00 AM

0

Peter Nilsson wrote:
> Here's something that achieves the same basic result, but in
> a (marginally) more maintainable way... [snip]
Paraphrasing:

#define TABLE(macro) macro( "the answer is", 6, 7 )macro( "foo", 1, 1 )macro( "bar", 2, 1 )macro( "zoo", 3, 1 )#define TABLEstr( str, num1, num2 ) str,
char *gStr[] = {TABLE(TABLEstr)};
#define TABLEnum( str, num1, num2 ) (num1*num2),
int gNum[] = {TABLE(TABLEnum)};
#include <stdio.h>
int main( void )
{
int j;
for( j = 0; j < sizeof gStr / sizeof *gStr; ++j)
printf( "%s %d\n", gStr[j], gNum[j]);
return 0;
}


Trouble is, there can be some low implementation-defined limit to
the size of an expanded macro (although I admit that nowadays,
all compilers that I use have it so high that I do not hit that
wall). Self-inclusion has the bonus that it does not make a long
macro when the table grows.

Also, when applied to computing the size of a struct to define
the size of a final field bringing the struct to some fixed size,
self-inclusion can look sufficiently similar to something familiar
that both an external programmer and a development environment
like Visual Studio will recognize the bulk of the struct, and be
able to pinpoint where each fields is declared. I can't see how
to achieve this with the "macro" technique.

Francois Grieu

Francois Grieu

10/22/2009 6:03:00 AM

0

Peter Nilsson wrote :
> Francois Grieu wrote:
>> Peter Nilsson wrote:
>>> Here's something that achieves the same basic result, but
>>> in a (marginally) more maintainable way... [snip]
>> Paraphrasing:
>>
>> #define TABLE(macro) >> macro( "the answer is", 6, 7 ) >> macro( "foo", 1, 1 ) >> macro( "bar", 2, 1 ) >> macro( "zoo", 3, 1 ) >> #define TABLEstr( str, num1, num2 ) str,
>
> I pass the delimiter as a second parameter. In C89, the
> grammar does not cater for the last enumerator having a
> comma. [C99 fixed this.]

All C compilers (including for embedded CPUs ) that I use
allow the final comma in constant declarations, even though
they claim only C89/C90 compatibility. And checking that
grammar, I read

3.5.7 Initialization

Syntax

initializer:
assignment-expression
{ initializer-list }
{ initializer-list , }

initializer-list:
initializer
initializer-list , initializer


Further, all but one C compiler that I use also allow the final
comma in an enum (which indeed is not in C89/C90), and the vendor
for said compiler has promised to improve that real soon now.


> why does it have to be _self_ inclusion?

Of course C does not require it, and most of the time
using a separate file is just fine. But there might be a
rule that the interface and implementation of a compilation
unit is split in exactly two files named like "foo.h"
and "foo.c". And the convention that the interface for a
compilation unit is exactly one file named like "foo.h"
is very common.
See Message-ID: <4ade2fde$0$405$426a74cc@news.free.fr>


>> Also, when applied to computing the size of a struct to
>> define the size of a final field bringing the struct to
>> some fixed size, self-inclusion can look sufficiently
>> similar to something familiar that both an external
>> programmer and a development environment like Visual
>> Studio will recognize the bulk of the struct, and be
>> able to pinpoint where each fields is declared. I can't
>> see how to achieve this with the "macro" technique.
>
> I don't really understand the example you're trying to give.
> Manually padding structs is difficult with or without macros.
> The simple option is to use a union...

The same message points that with union, either you need
anonymous union, or break compatibility with former code.

> [snip example of structure padding with macro]

One advantage of doing basically that with self-inclusion
rather than macro is that the location with struct declaration
and list of fields can be identified as such by a wider range
of programmers, and by development environments like Visual
Studio.

Also, I think that your padding size computation
> [...] 128 - sizeof(struct abc) [...]
is not robust enough. In fact I can't find a single way to
do it in a fully conformant way (and won't post my best
approximation without prior deep thinking about it).


Francois Grieu