473,320 Members | 1,694 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

File name macro

I understand that some compilers define a symbol that can be used
anywhere in the code in order to find out, at run time, the name of the
file where the code corresponding to the current execution instant is
implemented. This prompts two questions:

1) Is this an ANSI C feature, or just a compiler-dependent goody?

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?
Nov 14 '05 #1
20 2407
On Fri, 09 Apr 2004 19:43:18 GMT, Jim Ford <jf*****@excite.com> wrote:
I understand that some compilers define a symbol that can be used
anywhere in the code in order to find out, at run time, the name of the
file where the code corresponding to the current execution instant is
implemented. This prompts two questions:

1) Is this an ANSI C feature, or just a compiler-dependent goody?
Yes, it is an ISO C requirement. Section 6.10.8/1:

_ _FILE_ _ The presumed name of the current source file
(a character string literal)

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Nope.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #2

"Jim Ford" <jf*****@excite.com> a écrit dans le message de
news:pa****************************@excite.com...
I understand that some compilers define a symbol that can be used
anywhere in the code in order to find out, at run time, the name of the
file where the code corresponding to the current execution instant is
implemented. This prompts two questions:
Hi,

1) Is this an ANSI C feature, or just a compiler-dependent goody?
Yes, __FILE__
2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Yes, __func__, in C99.

Regis
Nov 14 '05 #3
Jim Ford <jf*****@excite.com> spoke thus:
2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


As Leor stated, the answer is no. However, you may find the __LINE__
macro to be useful.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #4
On Fri, 09 Apr 2004 19:32:28 GMT, Leor Zolman <le**@bdsoft.com> wrote:

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Nope.
-leor


Sorry! I guess there is. I'd never heard of it, and the Standard sneakily
hid it in a different section (6.4.2.2) than the others.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #5
On Fri, 9 Apr 2004 19:40:51 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
Jim Ford <jf*****@excite.com> spoke thus:
2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


As Leor stated, the answer is no. However, you may find the __LINE__
macro to be useful.


Leor was wrong, wrong, wrong... as I just discovered to my chagrin (for
making me look ignorant) but to my pleasant surprise (because it is there
at all), __func__ is actually a "predefined identifier" rather than a
"predefined macro name"... thus in a different section :-(
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #6
Leor Zolman <le**@bdsoft.com> spoke thus:
Leor was wrong, wrong, wrong... as I just discovered to my chagrin (for
making me look ignorant) but to my pleasant surprise (because it is there
at all), __func__ is actually a "predefined identifier" rather than a
"predefined macro name"... thus in a different section :-(


How spiteful of them! The fact remains, at least, that __LINE__ is a
very nice macro. So is this the identity of this __func__ identifier
implentation-defined? Presumably it needn't always be a macro, or the
standard wouldn't have been so devious regarding it (right?).

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #7
On Fri, 9 Apr 2004 19:57:04 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
Leor Zolman <le**@bdsoft.com> spoke thus:
Leor was wrong, wrong, wrong... as I just discovered to my chagrin (for
making me look ignorant) but to my pleasant surprise (because it is there
at all), __func__ is actually a "predefined identifier" rather than a
"predefined macro name"... thus in a different section :-(
How spiteful of them! The fact remains, at least, that __LINE__ is a
very nice macro. So is this the identity of this __func__ identifier
implentation-defined? Presumably it needn't always be a macro, or the
standard wouldn't have been so devious regarding it (right?).


I don't like attempting to answer questions in this group on topics that I
don't at least /think/ I've got a handle on. Since I discovered the
existence of __func__ only a few short minutes ago, I'll pass on trying to
provide the in-depth analysis at this point...
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #8
Christopher Benson-Manica wrote:
Jim Ford spoke thus:
2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?

As Leor stated, the answer is no.
However, you may find the __LINE__ macro to be useful.


cat main.c #include <stdio.h>

void function(void) {
fprintf(stdout, "%s\n", __func__);
}

int main(int argc, char* argv[]) {
function();
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c
./main

function

Nov 14 '05 #9

On Fri, 9 Apr 2004, Christopher Benson-Manica wrote:

Leor Zolman <le**@bdsoft.com> spoke thus:
Leor was wrong, wrong, wrong... as I just discovered to my chagrin (for
making me look ignorant) but to my pleasant surprise (because it is there
at all), __func__ is actually a "predefined identifier" rather than a
"predefined macro name"... thus in a different section :-(
How spiteful of them! The fact remains, at least, that __LINE__ is a
very nice macro. So is this the identity of this __func__ identifier

^^^^^^^
"why is," perhaps?
implementation-defined? Presumably it needn't always be a macro, or the
standard wouldn't have been so devious regarding it (right?).


Think about it. The macro-expansions of __FILE__ and __LINE__ don't
require information from the parser to work properly; they just expand
through pure preprocessor magic. __func__, on the other hand, requires
information that only the parser can give: the name of the current
function. Thus, it cannot be expanded by the C preprocessor; it's a
compile-time construct, not a "CPP-time" one. :)

I think N869 explains it really well, actually.

HTH,
-Arthur
Nov 14 '05 #10
Leor Zolman wrote:
Jim Ford <jf*****@excite.com> wrote:
I understand that some compilers define a symbol that can be used
anywhere in the code in order to find out, at run time, the name
of the file where the code corresponding to the current execution
instant is implemented. This prompts two questions:

1) Is this an ANSI C feature, or just a compiler-dependent goody?


Yes, it is an ISO C requirement. Section 6.10.8/1:

_ _FILE_ _ The presumed name of the current source file
(a character string literal)


That's __FILE__

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Nope.


Yup, for C99. From N869:

6.4.2.2 Predefined identifiers

Semantics

[#1] The identifier __func__ shall be implicitly declared by
the translator as if, immediately following the opening
brace of each function definition, the declaration

static const char __func__[] = "function-name";

appeared, where function-name is the name of the lexically-
enclosing function.53)
____________________

53)Note that since the name __func__ is reserved for any use
by the implementation (7.1.3), if any other identifier is
explicitly declared using the name __func__, the behavior
is undefined.

[#2] This name is encoded as if the implicit declaration had
been written in the source character set and then translated
into the execution character set as indicated in translation
phase 5.

[#3] EXAMPLE Consider the code fragment:

#include <stdio.h>
void myfunc(void)
{
printf("%s\n", __func__);
/* ... */
}

Each time the function is called, it will print to the
standard output stream:

myfunc

Forward references: function definitions (6.9.1).

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #11
On Sat, 10 Apr 2004 00:53:57 GMT, CBFalconer <cb********@yahoo.com> wrote:
Yes, it is an ISO C requirement. Section 6.10.8/1:

_ _FILE_ _ The presumed name of the current source file
(a character string literal)


That's __FILE__

I just copied and pasted from the Standard PDF. I guess I'll have to adjust
for whatever convention they're using for readability...

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Nope.


Yup, for C99. From N869:


Yah, hadn't all those follow-up posts shown up for you yet at this point?
Thanks,
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #12
Leor Zolman wrote:
CBFalconer <cb********@yahoo.com> wrote:

.... snip ...

Nope.


Yup, for C99. From N869:


Yah, hadn't all those follow-up posts shown up for you yet at
this point?


Nope, I work offline, download a herd, go through it, and
eventually reconnect. My ISP then procedes to redate/time
anything I send to the moment it receives it - reasonable,
considering the number of erroneous clock setting out there.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #13
"Régis Troadec" <re**@wanadoo.fr> wrote:

"Jim Ford" <jf*****@excite.com> a écrit dans le message de
news:pa****************************@excite.com. ..
[...][S]ome compilers define a symbol that can be used
[...] to find out, at run time, the [...] function names [...]?


Yes, __func__, in C99.


Indeed. Which leads to another question: is there any portable
way to find out during preprocessing, if or if not the underlying
implementation provides for __func__ ?

If e.g. I have a bunch of debugging functions that shall print
__FILE, __LINE__ and __func__ in C99 (or later ;-}), but still
compile and work with reduced functionality in pre-C99, is the
following a reasonable approach?

#if ( __STDC_VERSION__ < 199901L )
#define __func__ "<unknown>"
#endif

Opinions?

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Nov 14 '05 #14
Irrwahn Grausewitz <ir*******@freenet.de> wrote:
<snip>
#if ( __STDC_VERSION__ < 199901L )
#define __func__ "<unknown>"
#endif
Dread; make that something like:

#if ( ( __STDC_VERSION__ +0L ) < 199901L )
#define __func__ "<unknown>"
#endif
Opinions?


Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Nov 14 '05 #15

"Irrwahn Grausewitz" <ir*******@freenet.de> a écrit dans le message de
news:3c********************************@4ax.com...

Hi,
"Régis Troadec" <re**@wanadoo.fr> wrote:

"Jim Ford" <jf*****@excite.com> a écrit dans le message de
news:pa****************************@excite.com. ..
[...][S]ome compilers define a symbol that can be used
[...] to find out, at run time, the [...] function names [...]?
Yes, __func__, in C99.


Indeed. Which leads to another question: is there any portable
way to find out during preprocessing, if or if not the underlying
implementation provides for __func__ ?


I would say no. __func__ isn't a macro but a predefined identifier.
It's like a *hidden* local variable defined in any function.
(See 6.4.2.2 of the standard and elsethread for further information )
e.g. :
void myFunc()
{
static const char __func__ = "myFunc"; /* hidden */
/*...*/
}

Therefore, there is no way I think to find out __func__ until the file is
parsed, so no way to find it out during the preprocessing phase.
If e.g. I have a bunch of debugging functions that shall print
__FILE, __LINE__ and __func__ in C99 (or later ;-}), but still
compile and work with reduced functionality in pre-C99, is the
following a reasonable approach?

#if ( __STDC_VERSION__ < 199901L )
#define __func__ "<unknown>"
#endif
Opinions?
That is exactly what I would do if I were in your case.

Regards,

Regis

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

Nov 14 '05 #16
In <s3********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:
On Fri, 09 Apr 2004 19:32:28 GMT, Leor Zolman <le**@bdsoft.com> wrote:

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?


Nope.
-leor


Sorry! I guess there is. I'd never heard of it, and the Standard sneakily
hid it in a different section (6.4.2.2) than the others.


Of course it's in a different section: it's not (and cannot be) a
preprocessor feature. There is no way to detect a function name during
translation phases 1 to 4, which constitute the preprocessing stage.

The lower case spelling of the identifier is another clue that we're
not dealing with a macro.

But the most annoying thing is that it's not a C89 feature, yet a
conforming C89 implementation can provide it, since the name is in the
implementation name space. And C99 implementations are few and far
between, so portable C code doesn't have much use for __func__.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #17
In <vp********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:
Irrwahn Grausewitz <ir*******@freenet.de> wrote:
<snip>
#if ( __STDC_VERSION__ < 199901L )
#define __func__ "<unknown>"
#endif


Dread; make that something like:

#if ( ( __STDC_VERSION__ +0L ) < 199901L )
#define __func__ "<unknown>"
#endif
Opinions?


What makes you think the second version is any better? If the
implementation doesn't define it, __STDC_VERSION__ is guaranteed to be
evaluated to 0 in this context and this is good enough for your purposes.

To avoid relying on this feature, I prefer the following form of the
test, which is the most readable, IMHO:

#if !defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)

But this is not the most important point. The real problem is that you
define an identifier you have no business to define: __func__. This is
undefined behaviour under ALL the C standards. The right thing is the
equally trivial:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define FUNCNAME __func__
#else
#define FUNCNAME "<unknown>"
#endif

and use FUNCNAME in the rest of your code. Now, you're on as solid ground
as you could possibly be (under C89, even the defined(__STDC_VERSION__)
test is technically undefined behaviour, as this identifier could
theoretically mean "crash and burn if this pp_token is detected in
any context").

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #18
On 13 Apr 2004 13:41:54 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <s3********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:
On Fri, 09 Apr 2004 19:32:28 GMT, Leor Zolman <le**@bdsoft.com> wrote:

2) If it is an ANSI C feature, is there anything equivalent for
function names, rather than file names?

Nope.
-leor
Sorry! I guess there is. I'd never heard of it, and the Standard sneakily
hid it in a different section (6.4.2.2) than the others.


Of course it's in a different section: it's not (and cannot be) a
preprocessor feature. There is no way to detect a function name during
translation phases 1 to 4, which constitute the preprocessing stage.


I didn't say I was necessarily using my head when scanning the list of
preprocessor macro names looking for something resembling the word
"function"....

The lower case spelling of the identifier is another clue that we're
not dealing with a macro.
.... a clue I wasn't privy to before I'd ever seen its spelling.

But the most annoying thing is that it's not a C89 feature, yet a
conforming C89 implementation can provide it, since the name is in the
implementation name space. And C99 implementations are few and far
between, so portable C code doesn't have much use for __func__.


If one does happen to have a compiler that supports __func__, and wants to
use it while developing portable code, it shouldn't be too difficult to
wrap it up with the help of the preprocessor in order to selectively
disable it on other platforms. If there isn't a way to detect __func__
support automatically, then in the worst case the compiles would take a
-DFUNC_SUPPORTED (or whatever) as required, e.g.:

/*
* Portable use (or non-use) of __func__ in debug mode
*/

#include <stdio.h>

//#define FUNC_SUPPORTED
//#define NDEBUG

#ifdef FUNC_SUPPORTED
#define FUNC __func__
#else
#define FUNC ""
#endif

#ifdef NDEBUG
#define diagnose(file, line, func) ((void)0)
#else
void diagnose(const char *file, int line, const char *func)
{
printf("FILE: %s, LINE: %d", file, line);
if (*func)
printf(", Func: %s", func);
printf("\n\n");
}
#endif
int main()
{
printf("Hello, world\n");
diagnose(__FILE__, __LINE__, FUNC);

diagnose(__FILE__, __LINE__, FUNC);

diagnose(__FILE__, __LINE__, FUNC);
printf("Goodbye, world\n");
return 0;
}

-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #19
Da*****@cern.ch (Dan Pop) wrote:
In <vp********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes: <snip>
#if ( ( __STDC_VERSION__ +0L ) < 199901L )
#define __func__ "<unknown>"
#endif

<snip>[...] The real problem is that you
define an identifier you have no business to define: __func__. This is
undefined behaviour under ALL the C standards.
You're of course correct, shame on me.
The right thing is the
equally trivial:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define FUNCNAME __func__
#else
#define FUNCNAME "<unknown>"
#endif

and use FUNCNAME in the rest of your code. Now, you're on as solid ground
as you could possibly be (under C89, even the defined(__STDC_VERSION__)
test is technically undefined behaviour, as this identifier could
theoretically mean "crash and burn if this pp_token is detected in
any context").


Thanks, Dan.
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Nov 14 '05 #20
In <37********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:
If one does happen to have a compiler that supports __func__, and wants to
use it while developing portable code, it shouldn't be too difficult to
wrap it up with the help of the preprocessor in order to selectively
disable it on other platforms. If there isn't a way to detect __func__
support automatically, then in the worst case the compiles would take a
-DFUNC_SUPPORTED (or whatever) as required, e.g.:
This is NOT what we use to call portable programming in this newsgroup.
And you can do better than that, considering that C99 and later
implementations are supposed to provide __func__, so you don't need any
hints from the user when using such compilers. And you can do even
better, by allowing other names for the same feature (some C89 compilers
supported this feature under a different name, e.g. __FUNCTION__ in the
case of gcc); it would be downright stupid to limit yourself to the
compilers using the __func__ identifier.

So, dump the idea of using FUNC_SUPPORTED and ask the user to define
FUNC itself, as appropriate for a C89 compiler supporting the feature.
/*
* Portable use (or non-use) of __func__ in debug mode
*/

#include <stdio.h>

//#define FUNC_SUPPORTED
//#define NDEBUG

#ifdef FUNC_SUPPORTED
#define FUNC __func__
#else
#define FUNC ""
#endif


Replace the above by:

#ifndef FUNC
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define FUNC __func__
#else
#define FUNC "<unknown>"
#endif
#endif

Now, you are as flexible as you can be: if the user gives you a definition
for FUNC, you use it as such, otherwise you try to see if the compiler is
supposed to support __func__ for this purpose, if not, use the default
"<unknown>" name.

It's still not what I call portable code, since I have no guarantee that
I will ever see function names in the program's output. OTOH, it's
better than the guarantee that I'll *never* see function names in the
program's output.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Tim Eliot | last post by:
Just wondering if anyone has hit the following issue and how you might have sorted it out. I am using the command: DoCmd.TransferText acExportMerge, , stDataSource, stFileName, True after...
2
by: Jamie A. Landers | last post by:
I have a macro that runs to export a report. It dumps a report on the server in RTF format. Here's the problem that I am having. I would like for the report to have a custom file name daily, like...
11
by: Grim Reaper | last post by:
I am importing a .csv file into Access that has 37 fields. My problem is that sometimes the last field only has data at the end of the column (it looks like when you import a file into Access, for...
1
by: fresh | last post by:
I have a database that I periodically export to a text file for a Word mail merge. I have a query that finds all of the records with a null export date and a query that updates the export date to...
20
by: Jim Ford | last post by:
I understand that some compilers define a symbol that can be used anywhere in the code in order to find out, at run time, the name of the file where the code corresponding to the current execution...
6
by: hpy_awad | last post by:
I am writing stings ((*cust).name),((*cust).address)to a file using fgets but rabish is being wrote to that file ? Look to my source please and help me finding the reason why this rabish is being...
18
by: Torben Laursen | last post by:
Hi Can anyone tell me what is the short-cut to switch between a .h and .cpp file, thanks Torben Laursen ---
2
by: zswong | last post by:
Hi, I am new in Perl and need abit of help on the usage of file handler. I was trying to write a line into a file with file handler ID "oFile2_$macro", but it does NOT work with the following...
1
by: mrpknd57 | last post by:
Hi, I am new to Access/VBA can anyone help? I have a form with a button that runs a macro. I have been using the TransferText action within the macro to import a text file, from a specific...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
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...
1
isladogs
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...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
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)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.