Sign in

username:

password:



Not a member?

Search basicx



Search tips

Subscribe to basicx



basicx by Keywords

Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Ads

Discussion Groups

Discussion Groups | BasicX | * NetMedia * Can you confirm?

Discussion forum for the BasicX family of microcontroller chips.

* NetMedia * Can you confirm? - Dan Bielecki - Apr 10 5:04:00 2001

Can someone at NetMedia confirm something for me?
The Compiler/Downloader and Editor, What language is it written in?
The ActiveX Control objects (OCXs) seem to point to VB, but can someone
confirm that?

I think I'm onto something here with that v1.48 directory-trashing bug I
posted previously.

.db.
[Non-text portions of this message have been removed]





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )


Re: * NetMedia * Can you confirm? - Author Unknown - Apr 10 9:25:00 2001

Everything is written in VB.

Jack

--- In basicx@y..., "Dan Bielecki" <Dan.Bielecki@A...> wrote:
> Can someone at NetMedia confirm something for me?
> The Compiler/Downloader and Editor, What language is it written in?
> The ActiveX Control objects (OCXs) seem to point to VB, but can
someone
> confirm that?
>
> I think I'm onto something here with that v1.48 directory-trashing
bug I
> posted previously.
>
> .db. >
> [Non-text portions of this message have been removed]





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

RE: Re: * NetMedia * Can you confirm? - Dan Bielecki - Apr 10 23:32:00 2001

Jack,

Thank you for the response. I appreciate it. That is what I and others
thought. The ActiveX controls are a give-away.
Here is what I have uncovered so far in regards to the issue of directory
corruption. Please bare with it's length.

I develop under a main directory named @Development. Under it, there are
assorted subfolders named JAVA, HTML, Visual Basic, BasicX, ect...depending
on the language I am developing under at the time....Then under those, the
assorted projects and versions of the projects. This can lead to extensive
path names as far as length of an internal string goes.

I also have a directory name @Protoware (including the assorted language
sub-folders, version etc...) that is at the same level of of the
@Development folder. The @Protoware folder is where I write and experiment
with different modules and programs that aren't really "under development"
per say. They are more or less prototyping software modules that may or
may not ever make it into actual development.

What I have found since the upgrade to v1.48 is that both of these folders
can become corrupted over prolonged use of BasicX dev system under the
following conditions:

1) The original BasicX installation of the dev system is NOT directly a
child or parent folder under the @Development or @Protoware folders. The
folders contain only source and object code for different projects under
development. The BasicX dev system is installed under the Program Files
folder along the same lines that most programs are. The matter of the
original or a modified installation path has no effect on eliminating the
problem. BasicX is just separate from actual source members.

2) Since development is taking place outside of the BasicX installation
folder, one must click up-and-out of the installation folder using the
dialogue boxes... and then down into the desired folder. This dialog box
acts pretty standard so I dont think its really the culprit. One can never
be too sure though.

3) The original installation default path settings are left alone. The
dialog box path setting is unchanged from the initial installation of v1.48.
It is pointing to the default installation path settings under BasicX.
Since I may be developing different projects at different times, making any
type of changes to this setting really has no effect to me. I almost always
have to click up-and-out and point to what I want to work on at the time.
This may be an @Development on a CDRW or the @Development on my C drive.
These days, almost always to CDRWs so my projects are portable and
recoverable in the event of a hard disk crash. In this case, since a CD
directory structure is different then a disk, and its harder to corrupt it,
I receive a windows dialog box informing of an internal error and BasicX
ends abnormally sometimes when saving with the F2 key..

4) If no external interaction is done outside of BasicX, the directory
structure(s) will remain intact. Interaction being, no requests to Windows
Explorer or editing of a different BasicX source member in Notepad for
example. If I never leave the dev system for any reason, I'm fine.

5) If interaction is performed, such as editing a BasicX source in the dev
system, but also reviewing, browsing or editing of a different source member
under a different or same master folder (@Development or @Protoware) the
directory can become unstable, unusable and corrupted once the BasicX system
is eventually closed and the job is ends.

6) My entire development PC is up-to-date. This include Win2000 Pro
service packs, VB 6.0 service packs, IBM Aptiva firmware and BIOS updates.
Everything. The Aptiva series are very stable platforms and are very
automated in regards to firmware and BIOS updates. So is Windows 2000 Pro.
From an system operational point of view, Im current and on the cutting edge
of technology.

Based on all this...here's what Im think'n....

The @ character is a valid as far as naming conventions go for files and
folders. I've use it for years so certain folders appear at the top of my
directory listings...like in Windows Explorer, so I dont always have to go
searching and scrolling for my development folders. It appears before the
letters A-Z in ASCII sorting.

I also know, being a developer myself , that @ is a special string
formatting character in VB when writing string data. So Im thinking that
maybe the writes that occur in the BasicX system to the directory structures
are not being performed using standard routines or DLLs and are somehow
interpreting the @ symbol in the folder names as that of a formatting
character instead of part of the actual folder name. I dont feel VB itself
is directly a factor since a lot of code is written in VB these days and
there has never been issues with the @ symbol before in other packages
installed on my system. My own VB code also does not produce this effect.

The directories exist at the time....so that would be considered an update,
not a create, and if the @ symbol is in fact being evaluated somehow in the
BasicX logic as a formatter, then after evaluation, the path name would be
minus the @ symbol, shifted and formatted differently then the actual name
of the directory entry to update. That would be a problem.

Since the source can also be auto-saved at times this would mean that the
update is taking place to the file and disk sectors repeatedly in different
folders, at different times, (such as to the temp one under the dev system),
but upon program closure of the dev system the "final" beginning and ending
sectors of the actual data, are updated and closed, the directory entry is
then updated, or removed and created, depending on NetMedia programming
standards. This has to involve at least two strings. One for the temp, and
one for the actual path. There could be more, but for the sake of
this..lets say just two are involved. these strings would have to be
swapped in and out over time as the saves are happening...more so if the
auto-save is active. Every 10 minutes (default) the temp path would be
swapping into a string, executed upon and swapped out....Same goes for when
F2 is pressed.

There has to be some problem with this area since the folders become
corrupted repeatedly by using BasicX. I have used some of my other
language tools on source that exist under the @Development and @ Protoware
folders, (the JAVA tools , HTML tools, VB 6.0, straight Text, and some plain
old QuickBasic.), attempting the same steps and none of the others result in
the folder(s) becoming unusable. Im almost positive that its the BasicX dev
system writing inappropriate directory entries at some point either during
an auto save or at some point of the BasicX system in its overall
processing.

Please have the matter reviewed....and I hope all this (lengthy as it is)
helps in the evaluation and review of the v1.48 source code ! and thx again
for getting back to me.

.db. -----Original Message-----
From: [mailto:]
Sent: Tuesday, April 10, 2001 07:25 AM
To:
Subject: [BasicX] Re: * NetMedia * Can you confirm? Everything is written in VB.

Jack

--- In basicx@y..., "Dan Bielecki" <Dan.Bielecki@A...> wrote:
> Can someone at NetMedia confirm something for me?
> The Compiler/Downloader and Editor, What language is it written in?
> The ActiveX Control objects (OCXs) seem to point to VB, but can
someone
> confirm that?
>
> I think I'm onto something here with that v1.48 directory-trashing
bug I
> posted previously.
>
> .db. >
> [Non-text portions of this message have been removed] Yahoo! Groups Sponsor

>>
Enter Business Search Term above Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )