473,324 Members | 2,370 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,324 software developers and data experts.

Re: reformat to tool/editor-compliant C style?

On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.
what's wrong with that?!

I'm sure that made sense once to save disk space for the
source code, or something:-(
wouldn't replacing spaces with tabs do that? Were disks ever
*that* small? I've worked on old mini-computers and even
then we didn't try to save space at the *source* level.
The project's normal rule is "don't
reformat unnecessarily" since it makes source control merge/diff
difficult.
use a decent configuration control system and make sure
you don't mix source code changes with reformats. Clearly label
the reformat versions.

can't help you with indent

<snip>

--
Nick Keighley
Jul 4 '08 #1
18 2791
Nick Keighley writes:
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
>I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.

what's wrong with that?!
Tab width 8 is the norm elsewhere, at least in the Unix world and with
published ASCII text. So some code gets written with tab-width 4, some
with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I've substituted spaces):

int foo; /* hi there */
const char *barbaz[256]; /* and here */

becomes this when displayed with tab-width 8:

int foo; /* hi there */
const char *barbaz[256]; /* and here */
>I'm sure that made sense once to save disk space for the
source code, or something:-(

wouldn't replacing spaces with tabs do that?
Not if tab width indentation level. (e.g. 8 and 4).
Were disks ever *that* small? I've worked on old mini-computers and
even then we didn't try to save space at the *source* level.
Who knows. If the point was not to save space, I have no idea at all
what the point was.
>The project's normal rule is "don't reformat unnecessarily" since it
makes source control merge/diff difficult.

use a decent configuration control system and make sure
you don't mix source code changes with reformats. Clearly label
the reformat versions.
Actually I'm not sure what a configuration control system is, as opposed
to source control. This project is still using CVS, and I'm not going
to fight about that. In any case the reformatting changes will
certainly not pay attention to the "don't reformat" rule:-)

--
Hallvard
Jul 4 '08 #2
Hallvard B Furuseth schrieb:
Who knows. If the point was not to save space, I have no idea at all
what the point was.
The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.

You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47***********************@news.freenet.de>
Jul 4 '08 #3
You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.
If you wish to maintain vertical aligment for whatever reason, then
you have to use spaces.

Of course having vertical alignment in source code is a matter of
personal taste

Reducing indent (tab) size increases the number of nested blocks that
dont require line wrapping, or allows the use of longer variable
names.

Increasing the indent size reduces the risk of vertical alignment
being upset if the tab size is changed as possibly only a single tab
is required to maintain alignment
Jul 4 '08 #4
On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<ni******************@hotmail.comwrote in comp.lang.c:
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.

what's wrong with that?!

I'm sure that made sense once to save disk space for the
source code, or something:-(

wouldn't replacing spaces with tabs do that? Were disks ever
*that* small? I've worked on old mini-computers and even
then we didn't try to save space at the *source* level.
Apparently you never coded C under CP/M 80 on single density 8" floppy
disks.

Or Pascal on early micros where the storage medium was a cassette
tape. I say Pascal, because I don't actually remember a
cassette-based C for the original TRS-80.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jul 5 '08 #5
Jack Klein wrote:
On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<ni******************@hotmail.comwrote in comp.lang.c:
>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
>>I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.
what's wrong with that?!

>>I'm sure that made sense once to save disk space for the
source code, or something:-(
wouldn't replacing spaces with tabs do that? Were disks ever
*that* small? I've worked on old mini-computers and even
then we didn't try to save space at the *source* level.

Apparently you never coded C under CP/M 80 on single density 8" floppy
disks.
Forget the disks, getting the source in memory was enough of a challenge!

--
Ian Collins.
Jul 5 '08 #6
Johannes Bauer wrote:
Hallvard B Furuseth schrieb:
>Who knows. If the point was not to save space, I have no idea at all
what the point was.

The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.
Fortran lives !!
Jul 5 '08 #7
Hallvard B Furuseth wrote:
Nick Keighley writes:
>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
>>I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.
what's wrong with that?!

Tab width 8 is the norm elsewhere, at least in the Unix world and with
published ASCII text.
Er no, but thats a religious war so don't go there.

So some code gets written with tab-width 4, some
with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I've substituted spaces):

int foo; /* hi there */
const char *barbaz[256]; /* and here */

becomes this when displayed with tab-width 8:

int foo; /* hi there */
const char *barbaz[256]; /* and here */
So reset your editor to use tab widths of 4. Job done.
Jul 5 '08 #8
Mark McIntyre wrote:
>Hallvard B Furuseth wrote:
> So some code gets written with tab-width 4, some
with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I've substituted spaces):
int foo; /* hi there */
const char *barbaz[256]; /* and here */
becomes this when displayed with tab-width 8:
int foo; /* hi there */
const char *barbaz[256]; /* and here */

So reset your editor to use tab widths of 4. Job done.
I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

--
Hallvard
Jul 5 '08 #9
I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.
That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

Jul 6 '08 #10
Mark McIntyre wrote:
>
>I should have clarified: The code was _originally_ written with
tab width 4. But by now it's sprinkled with quite a bit written
with tab widht 8. Open-source project, several authors... So
it gets wrong either way.

That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Presumably you mean that some moron has tab-to-spaced your code
twice, once at 4s/t and once at 8s/t.

In which case why not just run it through indent, setting
appropriate tabs (not spaces)?
Your software seems to be absorbing the message attributions.
Please fix.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Jul 6 '08 #11
Mark McIntyre writes:
>I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.
Yes, and either way existing code gets displayed misaligned.
Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.
Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.

If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
int foo; /* ... */
struct Bar bar[256]; /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
int baz; /* ... */
struct Bar quux[256]; /* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. With tab-width 8, the
first example looks like
int foo; /* ... */
struct Bar bar[256]; /* ... */
With tab-width 4, the 2nd example looks like
int baz; /* ... */
struct Bar quux[256]; /* ... */

Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).
In which case why not just run it through indent, setting appropriate
tabs (not spaces)?
First, I don't know how other people _write_ code, in particular with
non-Emacs. Thus the question of what kind of style is easy to produce
with other editors.

Second, because indent isn't smart enough. With macro magic, multiline
macros, too creative formatting and macros etc. So I'll have to walk
through the result and clean up. Like this piece of formatting which
is just semantically wrong:

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */
} else if (bar) {
handle bar;

/* oh dear */
} else {
error();
}

Also indent doesn't really understand C, so I suppose it could make
semantic changes. Not sure that's worth worrying about though.
Probably more likely that I'd make a typo when cleaning up.

--
Hallvard
Jul 6 '08 #12
[Argh, forgot to untabify an example. Superseding article...]

Mark McIntyre writes:
>I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.
Yes, and either way existing code gets displayed misaligned.
Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.
Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.

If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
int foo; /* ... */
struct Bar bar[256]; /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
int baz; /* ... */
struct Bar quux[256]; /* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. With tab-width 8, the
first example looks like
int foo; /* ... */
struct Bar bar[256]; /* ... */
With tab-width 4, the 2nd example looks like
int baz; /* ... */
struct Bar quux[256]; /* ... */

Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).
In which case why not just run it through indent, setting appropriate
tabs (not spaces)?
First, I don't know how other people _write_ code, in particular with
non-Emacs. Thus the question of what kind of style is easy to produce
with other editors.

Second, because indent isn't smart enough. With macro magic, multiline
macros, too creative formatting and macros etc. So I'll have to walk
through the result and clean up. Like this piece of formatting which
is just semantically wrong:

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */
} else if (bar) {
handle bar;

/* oh dear */
} else {
error();
}

Also indent doesn't really understand C, so I suppose it could make
semantic changes. Not sure that's worth worrying about though.
Probably more likely that I'd make a typo when cleaning up.

--
Hallvard
Jul 6 '08 #13
On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
Mark McIntyre writes:
I should have clarified: *The code was _originally_ written with tab
width 4. *But by now it's sprinkled with quite a bit written with tab
widht 8. *Open-source project, several authors... *So it gets wrong
either way.
That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Yes, and either way existing code gets displayed misaligned.
Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. *Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.

If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
* * * * int * * * * * * * * * * foo; * * * * * * * * * */* ... */
* * * * struct Bar * * *bar[256]; * * * * * * * /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
* * * * int * * * * * * baz; * * * * * */* ... */
* * * * struct Bar * * *quux[256]; * * */* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. *With tab-width 8, the
first example looks like
* * * * int * * * * * * * * * * foo; * * * * * * * * * */* ... */
* * * * struct Bar * * *bar[256]; * * * * * * * /* ... */
I think I could live with that...
With tab-width 4, the 2nd example looks like
* * * * int * * * * * * baz; * * * * * */* ... */
* * * * struct Bar * * *quux[256]; * * */* ... */

Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).
In which case why not just run it through indent, setting appropriate
tabs (not spaces)?
no. *remove* all the tabs. Its the tabs that cause the problem.

First, I don't know how other people _write_ code, in particular with
non-Emacs. *Thus the question of what kind of style is easy to produce
with other editors.
Does emacs format your code that much? The editor I use fiddles
with the indentation a bit but otherwise leaves things alone
(if it tried to do anything else the feature would be rapidly
disabled- or the editoe dumped).

Second, because indent isn't smart enough. *With macro magic, multiline
macros, too creative formatting and macros etc. *So I'll have to walk
through the result and clean up.
I havn't used indent for a while but generally I thought it was pretty
good.
It tended to messs up some of my comment blocks.

>*Like this piece of formatting which
is just semantically wrong:
*semantically* wrong? Why? I hate K&R style { on the same
line as the code and comments outside the block. But the semantics
seem
plain enough.

* * * * /* try foo */
* * * * if (foo) {
* * * * * * * * handle foo;

* * * * /* otherwise try bar */
* * * * } else if (bar) {
* * * * * * * * handle bar;

* * * * /* oh dear */
* * * * } else {
* * * * * * * * error();
* * * * }
with my layout this would look like this.

if (foo)
{
handle foo;
}
else if (bar)
{
handle bar;
}
else
{
error();
}

or even

if (foo)
handle foo;
else if (bar)
handle bar;
else
error();

is *that* "semantically* wrong? I'm beginning to wonder
if one of us has a non-standard meaning for "semantic"...

Also indent doesn't really understand C,
ok...
so I suppose it could make
semantic changes. *
not by *my* definition of "semantic". I've never seen
indent screw up a correct peoce of code. The layout may
be strange but in my experience the code did the same thing
before and after.
Not sure that's worth worrying about though.
it would sure worry me if it was happening!

Probably more likely that I'd make a typo when cleaning up.
yes
--
Nick Keighley

"To every complex problem there is a simple solution... and it is
wrong."
-- Turski

Jul 7 '08 #14
Nick Keighley writes:
>On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
(...)
>With tab-width 8, the
first example looks like
* * * * int * * * * * * * * * * foo; * * * * * * * * * */* ... */
* * * * struct Bar * * *bar[256]; * * * * * * * /* ... */

I think I could live with that...
Well, two lines are hardly a problem. 20 gets a bit more annoying.
>>Mark McIntyre writes:
>>In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

no. *remove* all the tabs. Its the tabs that cause the problem.
Well, that's one option.
If people refrain from re-inserting tabs...
>First, I don't know how other people _write_ code, in particular with
non-Emacs. *Thus the question of what kind of style is easy to produce
with other editors.

Does emacs format your code that much? The editor I use fiddles
with the indentation a bit but otherwise leaves things alone
(if it tried to do anything else the feature would be rapidly
disabled- or the editoe dumped).
Emacs is programmable and very (too?) configurable, there is e.g. a
key binding to re-indent a block of code according to my chosen style.
In C files, the Tab key by default re-indents the line. It can be
configured to not do that, or to only do it when there is only
whitespace to the left of the cursor. Or I could write a function
which inserts spaces following non-tab characters but tab otherwise.
There is a key which inserts /* */ at the configured comment column
or moves an existing comment to that column. Etc.

I've hardly used other editors for C files, so I don't know how much
help they give and what kind of styles are natural to produce with
those. (E.g. if "indent with tab, align to a configured comment column
with spaces" is easy.)
>>*Like this piece of formatting which is just semantically wrong:

*semantically* wrong? Why? I hate K&R style { on the same line as the
code and comments outside the block. But the semantics seem plain
enough.
I meant the comment for one if-test is inside the previous {}, so there
little reason to expect any program to be able to indent it right.
Indentation gives (editing the quoted text a bit):

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */ <<< whoops <<<
} else if (bar) {
handle bar;
(...)

Yet it would have been so easy to write it "indent-friendly":

/* try foo */
if (foo) {
handle foo;
}

/* otherwise try bar */
else if (bar) {
handle bar;
(...)
>
>Also indent doesn't really understand C,

ok...
>so I suppose it could make semantic changes. *

not by *my* definition of "semantic". I've never seen
indent screw up a correct peoce of code. The layout may
be strange but in my experience the code did the same thing
before and after.
I've seen old documentation that warned that it could happen.
Getting confused and inserting/removing whitespace in strings or macro
arguments, or something. However I expect the keyword here is "old".
>Probably more likely that I'd make a typo when cleaning up.

yes
--
Hallvard
Jul 7 '08 #15
Hallvard B Furuseth wrote:
[Argh, forgot to untabify an example. Superseding article...]
its ok, I realised what you meant and in fact it worked on my display.
Also indent doesn't really understand C, so I suppose it could make
semantic changes.
I've /never/ heard of it doing that. It also understands C fine, afaik.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Jul 7 '08 #16
Johannes Bauer wrote:
Hallvard B Furuseth schrieb:
>Who knows. If the point was not to save space, I have no idea at all
what the point was.

The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.

You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.
I agree wholeheartedly. It is more flexible to use logical indentation
steps (tabs). Moreover, tabs are easier to edit than sequences of spaces
when you do not rely on automatic indentation. To make editing with a
simple editor easier I also never insert newlines in comment paragraphs
but use line wrapping instead.
August
Jul 8 '08 #17
August Karlstrom wrote:
>
.... snip ...
>
I agree wholeheartedly. It is more flexible to use logical indentation
steps (tabs). Moreover, tabs are easier to edit than sequences of spaces
when you do not rely on automatic indentation. To make editing with a
simple editor easier I also never insert newlines in comment paragraphs
but use line wrapping instead.
Ugh.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Jul 8 '08 #18
August Karlstrom <fu********@comhem.sewrites:
Johannes Bauer wrote:
>Hallvard B Furuseth schrieb:
>>Who knows. If the point was not to save space, I have no idea at all
what the point was.

The point of using tabs is that everyone can easily convert to
something convenient. I find a value of 4 spaces perfect, some
prefer 2, some prefer 8. I've also seen 3.

You suggest that you switch to 8 spaces (i.e. no tabs) which seems
to me like a really not that good idea. After all everyone should be
able to display it the way he/she wants - not the way the programmer
liked it. Code indented by spaces is an annoying pest, IMHO.

I agree wholeheartedly. It is more flexible to use logical indentation
steps (tabs). Moreover, tabs are easier to edit than sequences of
spaces when you do not rely on automatic indentation. To make editing
with a simple editor easier I also never insert newlines in comment
paragraphs but use line wrapping instead.
August
Absolute and total nonsense. This might have been true when working in
the stone age. No decent editor worth its salt cant not "mimic" tabs
indenting or outdenting using spaces.
Jul 8 '08 #19

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

Similar topics

10
by: Paul Kooistra | last post by:
I need a tool to browse text files with a size of 10-20 Mb. These files have a fixed record length of 800 bytes (CR/LF), and containt records used to create printed pages by an external company. ...
3
by: Just Curious | last post by:
Hello, I am doing some XSLT tranformations. I have a pretty complicated XML document with high level of nesting. I am looking for a tool that gives me the "hierarchial path" to the element I...
11
by: Shiperton Henethe | last post by:
Dreamweaver 4 Hi Can anyone recommend a decent utility for compressing HTML that is safe - i.e. that *definitely* doesn't mess with the appearance in any browsers. I run a growing website...
14
by: Akseli Mäki | last post by:
Hi, Hopefully this is not too much offtopic. I'm working on a FAQ. I want to make two versions of it, plain text and HTML. I'm looking for a tool that will make a plain text doc out of the...
3
by: Xiaopeng Xiong | last post by:
If there is any command for formatting all files under a directory, that would be best. But currently, formatting a single file is enough for me. I just can not type TAB at each line. Thanks a...
32
by: Roman | last post by:
Hello group, I'm wondering which authoring tool would be most flexible and useful for large websites using only html, css and javascrip. So far I've tried Dreamweaver MX, but have heard BBEdit...
14
by: Rajnish | last post by:
Hi C experts, Please suggest me best c programming language tool, which is like Jbuilder (for java) which suggest all avilable methods etc on typing the object. Best regards, Rajnish
3
by: Tina | last post by:
Does anyone know of an asp.net general purpose table editing tool that will allow users to add modify and delete data? Thanks, T
2
by: BigDave | last post by:
For a previous employer, I did a lot of BizTalk 2004 development, but am no longer doing so, and do not even have BizTalk installed. One of the things I miss is the BizTalk Scheme Editor, and how...
13
by: dmarrese | last post by:
I am a parent volunteer for a swim team website (makoswim.org) and am looking for a recommendation for a new web authoring tool . While I am technically oriented and have somehave some knowledge...
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: 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...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.