Beiträge von Der_Doc

Hi all,

und natürlich Alles Gute BugFix. Wenn mich nicht alles täuscht bist du doch heut am feiern. Also feier schön.

Gruß
Der_Doc

Ok,

bin angemeldet

MfG
Der_Doc

Hallo auch wenn es schon lange her ist aber mich gibt es noch

So ich habe ein kleines Projekt vor und zwar möchte ich den Quelltext des aktiven IE oder Firefox (Browser ist mir eigentlich egal) auslesen Ihn durchsuche und nötige Infos auslesen. Das Auslesen wird nicht das Problem eher den Richtigen Quelltext auszulesen.
Mit _INetGetSource kann ich den Quelltext auslese aber nur wenn ich eine URL habe die ich abfrage.
Da dies eine Webapplikation ist, die nochmal eigen Tabs in sich öffnet habe ich aber keine URL die ich abfragen kann.

Theorie:
Dorthin navigieren in der Webapplikation (Tab ist aktiv) und dann rechte Maustaste Quelltext anzeigen.

Praxis:
Dorthin navigieren in der Webapplikation (Tab ist aktiv) Autoitscript starten und den Quelltext auslesen und verarbeiten.

Gibt es hier vernünftige Ansätze?
Die ganzen fertigen IE Funktionen (HTML und Body read) fallen raus da es diese Tags nicht gibt.

Bitte um Hilfe und Beispiele.

MfG
Der_Doc

Tach,

bei mir regelt der PI mein Aquarium.

• Temperaturmessung
• Lichtsteuerung (4 Farben) über Relaisausgänge
• Pumpenüberwachung

In Planung PH Wert Messung und Wasserdurchfluss der Pumpe und der Zuleitung.

Und das macht er auch gut und zuverlässig.

Gruß
Der_Doc

Hi,

das ist ja nett das an einen gedacht wird aber mir war doch so als hätte BugFix am selben Tag Geburtstag.
Also auch da noch Alles Gute nachträglich.

Ja richtig da war doch was ....
BugFix dir auch noch nachträglich alles Gute ... da ich ja einen Schnaps-Geburtstag hatte, gab es bei mir schön 3 Flaschen Havana-Club mit den Kumpels.

BugFix danach habe ich auch mein Bett liebkost

Danke Euch allen.

MfG
Der_Doc

Was lange wartet wird gut
Was für ein sch Spruch ...... ALLES GUTE IHR BEIDEN

MfG
Der_Doc

Oh bin etwas spät aber trotzdem ALLES GUTE AUTOIT FORUM

PS: Der Archivauszug ist von ende April 2007. Ich war da schon fast 5 Monate dabei
Oh bin ich alt ... und hab so viel AutoIt erfahrung

MfG
Der_Doc

Hi,
soweit wie ich weiss musst du die Ausgaben entweder separat zählen oder du nutzt die Funktion COUNT in deiner Abfrage.

MfG
Der_Doc

So es ist wieder so weit.
Gun-Food Alles Gute zu deinem Ehrentag.

Weiter so auf weiter gute Jahre mit Autoit.de

MfG
Der_Doc

Hi,

also die Seite auf der du auchnochmal dein Problem gepostet hastm hat auch eine Hilfe in der folgendes steht:

netsh mbn disconnect interface="Mobile Breitbandverbindung 3"
ping Google -n 8
netsh mbn connect interface="Mobiles Breitband" connmode=name name="Vodafone.de"

Dann einfach mal bei Google

netsh mbn connect

eingeben und noch nen bischen lesen.

Und nicht vergessen auf:
http://social.technet.microsoft.com/Forums/de-DE/c…-wieder-trennen
deine Antwort auch posten

Auch hier nachträglich Alles Gute Pee.

MfG
Der_Doc

Ja BugFix natürlich spät nachträglich auch von mir noch alles Gute

MfG
Der_Doc

Ja nun wird es auch mal für mich Zeit mich zu bedanken.
Ich habe momentan einiges um die Ohren und komme deswegen selten dazu hier im Forum aktiv zu sein.
Aber trotzdem Danke an alle.

MfG
Der_Doc

Ja was soll ich nun anderes sagen?
Es steht doch schon alles.
Also Alles Gute zum Geburtstag.

MfG
Der_Doc

Ja ne dann mal alles gute Euch 5

MfG
Der_Doc

Oh mal wieder ein Thema für mich.
Also es gibt in SNMP 3 Wege den Traffic herauszubekommen.
Der erste ist ein Standard-Weg, den nutzen alle Monitoringprogramme.
SNMP Baum

1. Hersteller unabhängig (32-Bit Counter)
OID 1.3.6.1.2.1.2.2.1.16 die 16 ist dann schon der Wert z.B. für outOctets.
Hier kannst du auch noch andere Sachen abfragen. (siehe Bild)

2. Das sind die 32-Bit Werte die der Hersteller in seiner eigenen Mib angibt. Den Pfad dorthin kann die der Hersteller geben. Er liegt im Enterprice Zweig.
3. Das sind die 64-Bit Werte die der Hersteller in seiner eigenen Mib angibt. Den Pfad dorthin kann die der Hersteller geben. Er liegt im Enterprice Zweig.
Diese sind meist mit "Hi" gekenzeichnet.

32-64 Bit Counter
Auszug aus dem RFC2233 http://www.ietf.org/rfc/rfc2233.txt

Zitat

3.1.6. Counter Size

As the speed of network media increase, the minimum time in which
a 32 bit counter will wrap decreases. For example, a 10Mbs stream
of back-to-back, full-size packets causes ifInOctets to wrap in
just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that
interfaces be polled frequently enough not to miss a counter wrap
is increasingly problematic.
A rejected solution to this problem was to scale the counters; for
example, ifInOctets could be changed to count received octets in,
say, 1024 byte blocks. While it would provide acceptable
functionality at high rates of the counted-events, at low rates it
suffers. If there is little traffic on an interface, there might
be a significant interval before enough of the counted-events
occur to cause the scaled counter to be incremented. Traffic
would then appear to be very bursty, leading to incorrect
conclusions of the network's performance.

Instead, this memo adopts expanded, 64 bit, counters. These
counters are provided in new "high capacity" groups. The old,
32-bit, counters have not been deprecated. The 64-bit counters
are to be used only when the 32-bit counters do not provide enough
capacity; that is, when the 32 bit counters could wrap too fast.

For interfaces that operate at 20,000,000 (20 million) bits per
second or less, 32-bit byte and packet counters MUST be used. For
interfaces that operate faster than 20,000,000 bits/second, and
slower than 650,000,000 bits/second, 32-bit packet counters MUST
be used and 64-bit octet counters MUST be used. For interfaces
that operate at 650,000,000 bits/second or faster, 64-bit packet
counters AND 64-bit octet counters MUST be used.

These speed thresholds were chosen as reasonable compromises based
on the following:

(1) The cost of maintaining 64-bit counters is relatively high,
so minimizing the number of agents which must support them is
desirable. Common interfaces (such as 10Mbs Ethernet) should
not require them.

(2) 64-bit counters are a new feature, introduced in SNMPv2. It
is reasonable to expect that support for them will be spotty
for the immediate future. Thus, we wish to limit them to as
few systems as possible. This, in effect, means that 64-bit
counters should be limited to higher speed interfaces.
Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
fairly wide-spread so it seems reasonable to not require 64-
bit counters for these interfaces.

(3) The 32-bit octet counters will wrap in the following times,
for the following interfaces (when transmitting maximum-sized
packets back-to-back):

- 10Mbs Ethernet: 57 minutes,

- 16Mbs Token Ring: 36 minutes,
- a US T3 line (45 megabits): 12 minutes,

- FDDI: 5.7 minutes

(4) The 32-bit packet counters wrap in about 57 minutes when 64-
byte packets are transmitted back-to-back on a 650,000,000
bit/second link.

As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit
octet counter to wrap in just under 5 years. Conversely, an
81,000,000 terabit/second link is required to cause a 64-bit counter
to wrap in 30 minutes. We believe that, while technology rapidly
marches forward, this link speed will not be achieved for at least
several years, leaving sufficient time to evaluate the introduction
of 96 bit counters.

When 64-bit counters are in use, the 32-bit counters MUST still be
available. They will report the low 32-bits of the associated 64-bit
count (e.g., ifInOctets will report the least significant 32 bits of
ifHCInOctets). This enhances inter-operability with existing
implementations at a very minimal cost to agents.

The new "high capacity" groups are:

(1) the ifHCFixedLengthGroup for character-oriented/fixed-length
interfaces, and the ifHCPacketGroup for packet-based interfaces;
both of these groups include 64 bit counters for octets, and

(2) the ifVHCPacketGroup for packet-based interfaces; this group
includes 64 bit counters for octets and packets.
Network speeds are increasing. The range of ifSpeed is limited to
reporting a maximum speed of (2**31)-1 bits/second, or approximately
2.2Gbs. SONET defines an OC-48 interface, which is defined at
operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
Thus, ifSpeed is insufficient for the future, and this memo defines
an additional object: ifHighSpeed.

The ifHighSpeed object reports the speed of the interface in
1,000,000 (1 million) bits/second units. Thus, the true speed of the
interface will be the value reported by this object, plus or minus
500,000 bits/second.

Alles anzeigen

Ich hoffe ich konnte helfen.
Hier nochmal die Huawei-MIB http://www.oidview.com/mibs/2011/HUAWEI-MIB.html

MfG
Der_Doc

Na von mir natürlich auch ein .... IMMER WEITER SO .... und der Kopf ist immer das oberste Teil am Körper

MfG
Der_Doc

Spendenaufruf für unser AutoItforum

Hallo Leute,
es ist nun Weihnachten vorbei und wir sollten auch unseren AutoItserver mal etwas beschenken.
Jeder kann doch den Spendenbutton auf der linken-Seite sehen. Also drückt diesen doch mal und spenden eine Kleinigkeit.

Ich werde Ihn mal drücken.

Also ich wünsche Euch einen Guten Rutsch und noch schöne Feiertage.
MfG
Der_Doc

Hi,
ja Weihnachten ist gerettet.
Das wegen dem Downloads werde ich zwischen den Jahren mal überprüfen.
Da die Jungs ständig die Seite ändern greifen unsere Abfragen net immer.

MfG
Der_Doc