I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.
Thanks
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects) 22 3250
David T. Ashley wrote:
I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.
Probably a good place to start would be <stdint.hon one of the 64 bit
capable systems. I think you should use the standard types, rather than
redefining them in caps.
--
Ian Collins.
"Ian Collins" <ia******@hotmail.comwrote in message
news:52*************@mid.individual.net...
David T. Ashley wrote:
>I'm writing code which will compile on multiple Windows and multiple *nix platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32 or UINT64? I'm not sure how to sort out the various platforms and integer sizes, and some of it may even vary based on compiler options.
Probably a good place to start would be <stdint.hon one of the 64 bit
capable systems. I think you should use the standard types, rather than
redefining them in caps.
Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.hin
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.
I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.
Suggestions?
Dave.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
David T. Ashley a écrit :
"Ian Collins" <ia******@hotmail.comwrote in message
news:52*************@mid.individual.net...
>>David T. Ashley wrote:
>>>I'm writing code which will compile on multiple Windows and multiple *nix platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32 or UINT64? I'm not sure how to sort out the various platforms and integer sizes, and some of it may even vary based on compiler options. Probably a good place to start would be <stdint.hon one of the 64 bit capable systems. I think you should use the standard types, rather than redefining them in caps.
Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.hin
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.
I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.
Suggestions?
Dave.
Yes. Just copy your linux stdint.h to your Microsoft installation...
NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.
Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.
David T. Ashley <dt*@e3ft.comwrote:
I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
There are standard types defined in stdint.h, although the header is
available only in C99: uint32/64_t and uint_least32/64_t
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
jacob navia wrote:
David T. Ashley a écrit :
>"Ian Collins" <ia******@hotmail.comwrote in message news:52*************@mid.individual.net...
>>David T. Ashley wrote:
I'm writing code which will compile on multiple Windows and multiple *nix platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32 or UINT64? I'm not sure how to sort out the various platforms and integer sizes, and some of it may even vary based on compiler options.
Probably a good place to start would be <stdint.hon one of the 64 bit capable systems. I think you should use the standard types, rather than redefining them in caps.
Thanks for that info. I looked up this file (<stdint.h>) on my Linux box, and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in the include directory, so just to be sure I wasn't missing something, I searched Microsoft's site by "stdint.h" and got no matches.
I think the Microsoft tool chain doesn't have such a file. It isn't clear what to do, because even Windows will run on some 64-bit platforms.
Yes. Just copy your linux stdint.h to your Microsoft installation...
NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.
Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.
Although not standardised, _LLP64 (windows) and _LP64 (just about
everyone else) macros can and often are used to define the memory model
used on 64 bit platforms.
--
Ian Collins.
David T. Ashley wrote:
I looked up this file (<stdint.h>) on my Linux
box, and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.hin
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.
Take a look at Boost[1]. While it's mainly a C++ library, it also has a
compatibility module for platforms lacking explicitly sized integers. If
it doesn't already work for C, you will probably be able to easily make it
work.
One thing though, which wasn't brought up yet: it is best to avoid such
types. Depending on the context, it might be necessary though.
Uli
[1] www.boost.org
Ulrich Eckhardt wrote:
David T. Ashley wrote:
>>I looked up this file (<stdint.h>) on my Linux box, and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.hin the include directory, so just to be sure I wasn't missing something, I searched Microsoft's site by "stdint.h" and got no matches.
Take a look at Boost[1]. While it's mainly a C++ library, it also has a
compatibility module for platforms lacking explicitly sized integers. If
it doesn't already work for C, you will probably be able to easily make it
work.
One thing though, which wasn't brought up yet: it is best to avoid such
types. Depending on the context, it might be necessary though.
Why should they be avoided?
--
Ian Collins.
"David T. Ashley" wrote:
"Ian Collins" <ia******@hotmail.comwrote:
>David T. Ashley wrote:
>>I'm writing code which will compile on multiple Windows and multiple *nix platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32 or UINT64? I'm not sure how to sort out the various platforms and integer sizes, and some of it may even vary based on compiler options.
Probably a good place to start would be <stdint.hon one of the 64 bit capable systems. I think you should use the standard types, rather than redefining them in caps.
Thanks for that info. I looked up this file (<stdint.h>) on my
Linux box, and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find
<stdint.hin the include directory, so just to be sure I wasn't
missing something, I searched Microsoft's site by "stdint.h" and
got no matches.
I think the Microsoft tool chain doesn't have such a file. It
isn't clear what to do, because even Windows will run on some
64-bit platforms.
It doesn't exist under C90, only under C99. However limits.h
exists under both, so you could make your decisions based on the
values in that.
Most of the world has at least partially implemented C99, but
Microsoft is following its usual practice of undermining
standards. Just don't use any Microsoft software.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
On Sat, 27 Jan 2007 21:10:28 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>David T. Ashley a écrit :
>However, I also have Microsoft Visual C++. I couldn't find <stdint.hin the include directory, so just to be sure I wasn't missing something, I searched Microsoft's site by "stdint.h" and got no matches. Just copy your linux stdint.h to your Microsoft installation...
This may or may not achieve anything, depending on how stdint.h
defines the types. You may also end up copying several other headers.
Some of these may contain architecture-specific details which simply
aren't portable, and you'll either end up with incorrect definitions,
or definitions which surprise you.
Generally headers are _not_ portable between implementations.
>Of course you should remember that in 64 bit microsoft environment, long is 32 bits and under 64 bit linux it is 64 bits. The file would need at most a small editing change.
In my view, that sorta defeats the point. If you know the widths, then
you could just define the whole lot yourself in a private header with
a bunch of #ifs
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Jan 27, 12:04 pm, "David T. Ashley" <d...@e3ft.comwrote:
"Ian Collins" <ian-n...@hotmail.comwrote in
David T. Ashley wrote:
I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as
UINT32
or UINT64? I'm not sure how to sort out the various platforms and
integer
sizes, and some of it may even vary based on compiler options.
Probably a good place to start would be <stdint.hon one of the 64 bit
capable systems. I think you should use the standard types, rather than
redefining them in caps.Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
and it is just what I was looking for.
However, I also have Microsoft Visual C++. I couldn't find <stdint.hin
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.
I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.
Just get this: http://www.pobox.com/~qed/pstdint.h
Include that file for all platforms, and you are basically done. Its
as if all systems have a <stdint.hat that point. Its not 100% (and
I accept feedback on making the file better) but it covers all the
most common, important scenarios.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
Yes. Just copy your linux stdint.h to your Microsoft installation...
That's vanishingly unlikely to work. Does a Microsoft installation
happen to have headers called <features.h>, <bits/wchar.h>, and
<bits/wordsize.h>? Does it define a macro __WORDSIZE; if so, does it
have the same meaning as on Linux?
NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.
Yes, stdint.h is standard C. It's also worth mentioning that it's new
in the C99 standard, which many compilers don't currently implement.
Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.
If you want an implementation of <stdint.hthat can be used with a
pre-C99 implementation, take a look at
<http://www.lysator.liu.se/c/q8/index.html>.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On Jan 27, 7:09 pm, "David T. Ashley" <d...@e3ft.comwrote:
I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.
Start by including <limits.h>. If you want for example a 32 bit
unsigned type, check whether UINT_MAX is 0xffffffff, if not then check
whether ULONG_MAX is 0xffffff, otherwise #error (sort it out when you
run into the situation).
When running on a 64 bit system, you sometimes want 64 bit values
instead of 32 bit, and sometimes you don't. A variable that counts the
number of open windows in an application, or the number of children in
a family, doesn't have to be 64 bit. Variables counting the sizes of
things, or number of items, you will likely want to change in size on
a 64 bit system. I'd say checking whether SIZE_MAX == 2^64 - 1 is a
good indication. So you want some type that _does_ change on a 64 bit
system and needs to be named appropriately.
One hint: If you define such a type, give it a different type on a 32
bit vs. 64 bit system. For example, don't use long in both cases, but
use int for 32 bit (if it is large enough) and long for 64 bit (if it
is large enough). That way you can find mistakes where the wrong type
is used, because either on a 32 bit system or a 64 bit system the
compiler will produce an error.
"Ian Collins" <ia******@hotmail.comwrote in message
>
>One thing though, which wasn't brought up yet: it is best to avoid such types. Depending on the context, it might be necessary though.
Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.
ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
>>
>>One thing though, which wasn't brought up yet: it is best to avoid such types. Depending on the context, it might be necessary though.
Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very
rarely it is necessary to use a short type to save memory or a big
type to hold a huge value, but rarely.
ANSI have unfortunately decided that it is more important to support
4096 million character strings on 32 bit machines than to have a
clean language, and muddied the waters.
Nonsense. ISO has decided that it is important to not invalidate
clean existing code, as did the ANSI committee about 20 years ago.
The result has been almost 100% acceptance of the C90 standard, and
C99 will eventually be accepted. However the urge to advance there
is much smaller, simply because C90 did such a good job, and some
C99 extensions are a bear to implement.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
One thing though, which wasn't brought up yet: it is best to avoid such
types. Depending on the context, it might be necessary though.
Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.
ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.
One common complaint I hear from my colleagues, (who're Java bigots),
in defense of their reluctance to use C, is that it's types are too
few and primitive. I suppose it's a common argument on the bullet
lists of advocates of 4GLs.
"christian.bau" <ch***********@cbau.wanadoo.co.ukwrote in message
When running on a 64 bit system, you sometimes want 64 bit values
instead of 32 bit, and sometimes you don't. A variable that counts the
number of open windows in an application, or the number of children in
a family, doesn't have to be 64 bit.
No, but you need a lot of open desktops or a lot of families for it to
matter that the integer is 64 bits.
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
What happend to the other attributions?
>>>One thing though, which wasn't brought up yet: it is best to avoid such types. Depending on the context, it might be necessary though. Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.
From the above I guess that you haven't worked on embedded systems or
drivers, where size very often does matter.
ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.
Now that's just silly.
--
Ian Collins.
santosh said:
<snip>
One common complaint I hear from my colleagues, (who're Java bigots),
in defense of their reluctance to use C, is that it's types are too
few and primitive. I suppose it's a common argument on the bullet
lists of advocates of 4GLs.
I'm a great fan of 4GLs, but I see type multiplicity as something of a mixed
blessing. In any case, many of those 4GLs are written in C in the first
place. I once used a fabulous 4GL called KnowledgeMan. The language was a
sort of cross between C and BASIC. Types were almost non-existent, actually
- just numbers, strings, and database records, if I recall correctly. But
you got SQL, you got an evaluation operator for ripping the quotes off
strings, you got a built-in spreadsheet, you could read program code off
the disk and load it into the spreadsheet and then execute it from there
(because, would you believe, this was quicker - using the spreadsheet as a
sort of RAM disk)... oh, all sorts of tricks. It even had a sort of expert
system bolted on. That was one fabulous 4GL! But lotsatypes? No.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
"Ian Collins" <ia******@hotmail.comwrote in message
>It is just a nuisance to everyone if integers aren't ints. Very rarely it is necessary to use a short type to save memory or a big type to hold a huge value, but rarely.
From the above I guess that you haven't worked on embedded systems or
drivers, where size very often does matter.
When I campaign for 64 bit ints, that is on systems with 64 bit address
buses.
Oddly enough the last embedded system I programmed was a DSP which did have
wide integer types and no memory to speak of. However it didn't have a C
compiler.
"santosh" <sa*********@gmail.comwrote in message
Malcolm McLean wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
> One thing though, which wasn't brought up yet: it is best to avoid such types. Depending on the context, it might be necessary though.
Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very rarely it is necessary to use a short type to save memory or a big type to hold a huge value, but rarely.
ANSI have unfortunately decided that it is more important to support 4096 million character strings on 32 bit machines than to have a clean language, and muddied the waters.
One common complaint I hear from my colleagues, (who're Java bigots),
in defense of their reluctance to use C, is that it's types are too
few and primitive. I suppose it's a common argument on the bullet
lists of advocates of 4GLs.
Virtually all data consists of either numbers or letters. The exception is
bitstream data which is usually either numbers or letters in some compressed
format.
So you need numbers, characters and bytes. And the ability to build up
higher lever structures from these atoms. Anything else is needed for
machine efficiency, which is often a real concern, but increasingly less so.
Malcolm McLean wrote, On 30/01/07 07:44:
"santosh" <sa*********@gmail.comwrote in message
>Malcolm McLean wrote:
>>"Ian Collins" <ia******@hotmail.comwrote in message One thing though, which wasn't brought up yet: it is best to avoid such types. Depending on the context, it might be necessary though. > Why should they be avoided?
It is just a nuisance to everyone if integers aren't ints. Very rarely it is necessary to use a short type to save memory or a big type to hold a huge value, but rarely.
ANSI have unfortunately decided that it is more important to support 4096 million character strings on 32 bit machines than to have a clean language, and muddied the waters.
One common complaint I hear from my colleagues, (who're Java bigots), in defense of their reluctance to use C, is that it's types are too few and primitive. I suppose it's a common argument on the bullet lists of advocates of 4GLs.
Virtually all data consists of either numbers or letters. The exception is
bitstream data which is usually either numbers or letters in some compressed
format.
I disagree. I still do a lot of work with data which is logically one of
a discrete number of values where the numeric representation used has no
meaning. In fact, I can't think of any tables in the over 300 tables in
a large application that do *not* have something which is an enumerated
type. Yes, they are stored as numbers, but that is just because we can't
store them as anything else.
So you need numbers, characters and bytes. And the ability to build up
higher lever structures from these atoms. Anything else is needed for
machine efficiency, which is often a real concern, but increasingly less so.
No, other types are "needed"[1] for things other than efficiency.
Sometimes they map better to the real world problem that numbers,
characters or higher level structures build on these.
Personally I would have found the addition of a real enumeration type
and Pascal like sub-range types to have been more useful than a lot of
the things such as complex numbers that were added with C99. However, if
I want Pascal (or a derivative of similar language) I know where to find it.
[1] Obviously one can do without them but they are useful.
--
Flash Gordon
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
Malcolm McLean wrote, On 30/01/07 07:44:
>Virtually all data consists of either numbers or letters. The exception is bitstream data which is usually either numbers or letters in some compressed format.
I disagree. I still do a lot of work with data which is logically one of a
discrete number of values where the numeric representation used has no
meaning. In fact, I can't think of any tables in the over 300 tables in a
large application that do *not* have something which is an enumerated
type. Yes, they are stored as numbers, but that is just because we can't
store them as anything else.
You are right. It is not adequate to treat enums as integers.
Actually, if you think about it, a char is just a special case of an enum.
>
Personally I would have found the addition of a real enumeration type and
Pascal like sub-range types to have been more useful than a lot of the
things such as complex numbers that were added with C99. However, if I
want Pascal (or a derivative of similar language) I know where to find it.
[1] Obviously one can do without them but they are useful.
There is strong case for a standard defined complex structure, also 3d
vectors / points. However they don't really qualify as atomic types because
you also want to treat the components as scalars for some purposes.
enums are a different kettle of fish. For instance a lot of my data is DNA
or amino acid sequences. I think of it as character data because that is the
conventional representation. However a DNA base is not really a character. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chris Uwins |
last post by:
Hi there, i know theres a number of ways I can achieve this but want
to know the best, (but still quite simple).
Up until a year ago I never used Access but have designed a few
databases for...
|
by: Fr?d?ric Ledain |
last post by:
Hi.
I have to design new API, which some of them have to return a string.
I have mixed feelings about the various strategies I can choose :
1. API(char *s, long *size)
=> the client gives a...
|
by: bobwansink |
last post by:
Hi, I'm relatively new to programming and I would like to create a C++
multi user program. It's for a project for school. This means I will
have to write a paper about the theory too. Does anyone...
|
by: Nate |
last post by:
I am in a slight predicament trying to determine the most efficient and
effective way to connect/disconnect from a database within a business object
(c# dll). I'm also keeping in mind the concept...
|
by: maciek |
last post by:
Hi,
I was wondering if anyone could suggest me a book/article/tutorial on
Exception Handling in multi tier Windows Apps. What are the best
practices/ways to implement EH in multi tier...
|
by: Joe |
last post by:
Is any one charting packing considered to be the "best"? We've used ChartFX
but wasn't too happy about the way data had to be populated along with some
other issues which slip my mind right now and...
|
by: CptDondo |
last post by:
I have a small, embedded app that uses a webserver to serve up pages
showing status, etc.
Right now all the pages are hard-coded in English. We need to provide
multi-lingual support.
All of...
|
by: MrQuan |
last post by:
G'day all,
I have a requirement to communicate between two or more PCs over the
Internet, however I have no idea how to go about this.
I'm not talking about a chat programme as such, I want to...
|
by: Jeff |
last post by:
I need to read about 100 lines of a csv file into memory.
Each line contains 6 fields.
What is the best way to store this into memory and then read it back.
Is a array of a multi- dimsion...
|
by: trullock |
last post by:
Hi,
Can anyone suggest the best way to go about the following...
I'm tracking clicks (mouse down x,y coordinates) on a web page by
using some javascript to create an XHR which sends the...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM).
In this month's session, the creator of the excellent VBE...
|
by: DolphinDB |
last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation.
Take...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: Aftab Ahmad |
last post by:
Hello Experts!
I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
|
by: Aftab Ahmad |
last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below.
Dim IE As Object
Set IE =...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: marcoviolo |
last post by:
Dear all,
I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
| |